From dawid.weiss at gmail.com Mon Sep 2 02:17:20 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 2 Sep 2013 11:17:20 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> <521BFBD4.7090800@oracle.com> Message-ID: I've traced the assembly on a running instance. The problem is quite interesting -- the code in question is purely computational, I still don't see how G1GC can be of importance here. In short what's happening is a method gets inlined in a larger loop more than once and a field access is placed on the esp spill. The problem is both of these inlines use a different spill slot and one of the updates is not properly propagated -- it is saved to one spill slot, then the code execution flow returns to the top of the loop and another inline reads a stale value from another spill slot. When you disable escape analysis everything works as expected. The crucial block is: 7e25 B1020: # B405 B1021 <- B1017 B1019 Freq: 0.00811184 // XXX jump from b1017 7e25 MOV EBX,[ESP + #136] // ebx = 80e 7e2c MOV ECX,EBX 7e2e INC ECX // ecx = 80f, increment. 7e2f MOV [ESP + #144],ECX // this is the incremented spill but it never gets propagated to [esp + #136] or re-read from memory. 7e36 MOV EBX,[ESP + #132] 7e3d MOV [EBX + #12],ECX ! Field: org/apache/lucene/index/ByteSliceReader.upto 7e40 MOV EBX,[ESP + #152] 7e47 TEST EBX,EBX 7e49 Jne B405 P=0.999999 C=-1.000000 // taken, null check The incremented local value of upto gets saved to [ESP + #144] and to memory but upon reiterating the loop it is re-read from [ESP + #136] so it looks like a dependency is missed somewhere in the graph causing escape analysis to fail. Ehm, obviously I have no idea how or where to fix this in the JVM code :) Full optoassembly dump and annotated opto assembly analysis is here: http://www.cs.put.poznan.pl/dweiss/tmp/hotspot-bug-analysis.zip Let me know if I can do anything else. Dawid On Tue, Aug 27, 2013 at 9:15 AM, Dawid Weiss wrote: > Thanks Vladimir. I had the impression I may be looking at the > interpreter. Just for completeness, I also thought/tried the following > ways to stop at the jitted code: > > 1) call Windows debugger API endpoints from kernel32 -- > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx > > via JNI/ JNA. This worked surprisingly well -- you can even wait for > the debugger to attached to the code in a loop, works like a charm. :) > Although once you break into the debugger I again couldn't make sense > of the stack -- probably the infrequent call causes a deopt again and > we're back in the interpreter. > > 2) use Unsafe to force a null pointer dereference :) This should send > a debugger signal, right? I didn't try it though, didn't have the time > yet. I suspect it may be moved to an infrequent trap too and we're > back where we started, eh. > >> I still did not have time to look on your logs. > > No worries, it's been a very very educational experience for me. > Besides, I used to write tons of assembly (not on x86) and it actually > feels very good to be back at the assembly mnemonic level ;) > > Don't spoil my weekend pet project :) And seriously -- if you want to > check out those logs let me know in advance and I'll prepare an update > with hsx-tip if needed. > > Dawid > > On Tue, Aug 27, 2013 at 3:07 AM, Vladimir Kozlov > wrote: >> Dawid, >> >> Let it crush with AbortVMOnException (without ShowMessageBoxOnError) and >> look on call stack in hs_err_pidxxx.log file. Jited code usually have >> uncommon trap for exceptions so the method most likely was deoptimized and >> you will see interpeter frames on call stack instead of compiled/jited. >> There should be deoptimization event listed down in hs_err_pidxxx.log which >> may say in which address in jited code it hit uncommon trap. You can look on >> it in optoassembly output. Then during method compilation >> (-XX:+PrintCompilation -Xbatch -XX:CICompilerCount=1 should give you info >> when the method is compiled, you can verify it in Compile() by >> this->method()->print()) in debugger stop in ciEnv::register_method() after >> call to nmethod::new_nmethod(). nm->insts_begin() shows where instructions >> start. Add instruction offset from optoassembly and set breakepoint at that >> address. This way you can stop in jited code. >> >> G1 affects inlining since its write barriers code size is larger then other >> collectors (it has pre and post barriers for oop stores). >> >> I still did not have time to look on your logs. >> >> Vladimir >> >> >> On 8/26/13 12:56 PM, Dawid Weiss wrote: >>>> >>>> An ideal scenario and what I want to achieve is I'd like to stop on an >>>> assertion somewhere in the jitted code and go back to it to follow the >>>> execution (so that I can see what code is responsible for the issing >>> >>> increment). I'll need to sync this up (manually or otherwise) with the >>> optoassembly too [...] >>> >>> Would somebody be so kind and provide some light on whether the above >>> is feasible? I'm getting up to speed with visual studio -- haven't >>> used assembly-level debugging in a longer while -- but I'm having >>> troubles connecting the dots with verbose optoassembly output (the >>> addresses don't seem to match). Thanks and again, apologies if it's >>> something trivial but I couldn't find any helpful resources on the >>> net. >>> >>> Dawid >>> >>> On Sun, Aug 25, 2013 at 9:43 PM, Dawid Weiss >>> wrote: >>>> >>>> I know why the assertion is hit. I still don't know (and probably >>>> won't figure it out) why it is so difficult to reproduce or which >>>> optimization leads to it. >>>> >>>> In short, the following code in ByteSliceReader#readByte: >>>> >>>> public byte readByte() { >>>> assert !eof(); >>>> assert upto <= limit; >>>> if (upto == limit) { >>>> nextSlice(); >>>> } >>>> return buffer[upto++]; >>>> } >>>> >>>> is inlined in a number of places. If I include: >>>> >>>> public byte readByte() { >>>> assert !eof(); >>>> assert upto <= limit; >>>> if (upto == limit) { >>>> nextSlice(); >>>> baz = upto; >>>> } >>>> return buffer[upto++]; >>>> } >>>> static int baz; >>>> >>>> I see a number of assignments to 'baz'. This is because methods like >>>> readVInt fork out many conditional branches, as in: >>>> >>>> public int readVInt() throws IOException { >>>> byte b = readByte(); >>>> if (b >= 0) return b; >>>> int i = b & 0x7F; >>>> b = readByte(); >>>> i |= (b & 0x7F) << 7; >>>> if (b >= 0) return i; >>>> b = readByte(); >>>> i |= (b & 0x7F) << 14; >>>> if (b >= 0) return i; >>>> b = readByte(); >>>> i |= (b & 0x7F) << 21; >>>> if (b >= 0) return i; >>>> b = readByte(); >>>> // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste >>>> errors: >>>> i |= (b & 0x0F) << 28; >>>> if ((b & 0xF0) == 0) return i; >>>> throw new IOException("Invalid vInt detected (too many bits)"); >>>> } >>>> >>>> One of these executions (when upto == limit, and possibly with some >>>> other upper condition) leads to missing increment on buffer[upto++] -- >>>> upto remains unmodified (but the value at buffer[upto] is returned >>>> properly). Because upto is moved to a register in many of those >>>> inlined methods I suspect either the register may be incremented and >>>> not saved or the increment may be removed due to some local escape >>>> analysis magic (that has to be incorrect, obviously). How G1GC >>>> interacts with all this (remember, it only happens with G1GC) I have >>>> no clue. >>>> >>>> Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't >>>> make much sense of it. I also dug into some of the opto assembly >>>> branches trying to map them back into the original bytecode, but it's >>>> a very long process -- had to map PcDesc manually to the assembly >>>> offset, then go to bytecode again. Then I fired visual studio and >>>> halted it like Vladimir mentioned: >>>> -XX:AbortVMOnException=java.lang.AssertionError >>>> -XX:+ShowMessageBoxOnError >>>> >>>> Once I attach to the halted JVM I "break all" and I see the reported >>>> thread's stack trace halted inside ntdll (with the closest JVM frame >>>> stopped at get_deopt_original_pc). The frames below it don't seem to >>>> make much sense to me -- they don't seem to point to any addresses >>>> reported in the compilation log (PcDesc clauses). I'm a complete >>>> newbie to this, so I apologize if it's a lame question, but how can I >>>> find out which part of the original jitted code this assertion was >>>> invoked from? >>>> >>>> An ideal scenario and what I want to achieve is I'd like to stop on an >>>> assertion somewhere in the jitted code and go back to it to follow the >>>> execution (so that I can see what code is responsible for the missing >>>> increment). I'll need to sync this up (manually or otherwise) with the >>>> optoassembly too, otherwise I'll probably lose any remaining hair >>>> trying to figure out what's what :) >>>> >>>> A hint (or any other pointer; RTFM) would be very welcome. >>>> >>>> Dawid >>>> >>>> >>>> On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss >>>> wrote: >>>>> >>>>> One follow-up with respect to those encoded integers -- I swapped the >>>>> correct and incorrect sequence in my last e-mail, sorry. I then also >>>>> added a sysout here: >>>>> >>>>> @@ -451,6 +453,7 @@ >>>>> termFreq = 1; >>>>> } else { >>>>> termFreq = freq.readVInt(); >>>>> + System.err.print("# (tf): " + termFreq + " "); >>>>> } >>>>> } >>>>> >>>>> With this the assertion is no longer hit but it shows where the >>>>> difference in numbers comes from: >>>>> >>>>> Correct sequence is: >>>>> >>>>> # (eof) >>>>> # (code): 0 >>>>> # (tf): 3 >>>>> # (code): 4 >>>>> # (tf): 3 >>>>> # (code): 2 >>>>> # (tf): 5 >>>>> # (code): 2 >>>>> # (tf): 2 >>>>> # (code): 3 >>>>> # (code): 5 >>>>> # (code): 2 >>>>> >>>>> And the incorrect, assertion-hit run shows: >>>>> >>>>> # (eof) >>>>> # (code): 0 >>>>> # (code): 3 >>>>> # (code): 4 >>>>> # (code): 3 >>>>> # (code): 2 >>>>> # (code): 5 >>>>> # (code): 2 >>>>> # (code): 2 >>>>> # (code): 3 >>>>> >>>>> So there's something odd happening after the first readvint which >>>>> returns 0 -- the next number that should be read by: >>>>> >>>>> termFreq = freq.readVInt(); >>>>> >>>>> is re-read as the next code. >>>>> >>>>> Dawid >>>>> >>>>> >>>>> On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss >>>>> wrote: >>>>>> >>>>>> Thanks for comments guys. >>>>>> >>>>>>> It is great that you can build fastdebug VM. I assume that if I give >>>>>>> you a >>>>>>> patch to try you can also build with it. >>>>>> >>>>>> >>>>>> Yes, absolutely. >>>>>> >>>>>>> First, you can run with next options and then send zipped output >>>>>>> (related >>>>>>> part before the method compilation and optoassembler output, don't use >>>>>>> hsdis >>>>>>> for that) and hs_err file when test fails: >>>>>> >>>>>> >>>>>> I did that. Used the options you requested -- a full log of all I did >>>>>> is included in the ZIP file here: >>>>>> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >>>>>> >>>>>> Cat debug-files\debug-log.txt. There are several runs included in that >>>>>> ZIP file, in short: >>>>>> >>>>>> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >>>>>> debug-log.txt): >>>>>> 001-no-abort-on-assertion >>>>>> 002-no-abort-on-assertion >>>>>> >>>>>> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >>>>>> 003-with-abort-on-assertion >>>>>> 004-with-abort-on-assertion >>>>>> >>>>>> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >>>>>> 005-hsx-tip >>>>>> 006-hsx-tip >>>>>> >>>>>> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >>>>>> build, so only compilation logs available). >>>>>> 007-excluded-readvint >>>>>> >>>>>>> Looking on java code in FreqProxTermsWriterPerField::flush() and based >>>>>>> on >>>>>>> LUCENE-5168 report generated code somehow missed EOF check. Am I >>>>>>> right? This >>>>>>> is why the Assert is thrown? >>>>>> >>>>>> >>>>>> It's not the only method it trips on. Depending on the seed the >>>>>> problem shows up in different places. For the dumps I included the >>>>>> issue seems to be here: >>>>>> >>>>>>> } else { >>>>>>> final int code = freq.readVInt(); >>>>>>> if (!readTermFreq) { >>>>>>> docID += code; >>>>>>> termFreq = -1; >>>>>> >>>>>> >>>>>> If I add sysouts as in: >>>>>> >>>>>> Index: >>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>> =================================================================== >>>>>> --- >>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>> (revision 1512807) >>>>>> +++ >>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>> (working copy) >>>>>> @@ -427,6 +427,7 @@ >>>>>> //System.out.println(" cycle"); >>>>>> final int termFreq; >>>>>> if (freq.eof()) { >>>>>> + System.err.print("# (eof)"); >>>>>> if (postings.lastDocCodes[termID] != -1) { >>>>>> // Return last doc >>>>>> docID = postings.lastDocIDs[termID]; >>>>>> @@ -442,6 +443,7 @@ >>>>>> } >>>>>> } else { >>>>>> final int code = freq.readVInt(); >>>>>> + System.err.print("# (code): " + code + " "); >>>>>> if (!readTermFreq) { >>>>>> docID += code; >>>>>> termFreq = -1; >>>>>> >>>>>> then for a constant seed you'll get an identical sequence of values. >>>>>> Once the assertion hits though, the sequence deviates. Comparing a >>>>>> passing run (excluding readvint) and a failing run I get a lot of >>>>>> initial aligned outputs and then a deviation: >>>>>> >>>>>> (correct run): >>>>>> # (eof) >>>>>> # (eof) >>>>>> # (eof) >>>>>> # (code): 0 >>>>>> # (code): 3 >>>>>> # (code): 4 >>>>>> # (code): 3 >>>>>> >>>>>> (incorrect run): >>>>>> # (eof) >>>>>> # (eof) >>>>>> # (eof) >>>>>> # (code): 0 >>>>>> # (code): 4 <- wtf? >>>>>> # (code): 2 >>>>>> # (code): 2 >>>>>> >>>>>> How can a variable encoded integer be misinterpreted from 3 to 4 is >>>>>> beyond me, sorry. But it's not an EOF condition I think, at least the >>>>>> deviation happens where the original run had was entering (code) >>>>>> branch. >>>>>> >>>>>>> Could you also send latest version of FreqProxTermsWriterPerField.java >>>>>>> you >>>>>>> are testing? >>>>>> >>>>>> >>>>>> I'm testing against a fixed branch (the info is included in >>>>>> debug-log.txt). >>>>>> >>>>>> If there's anything else I can do, let me know. I'm also curious how >>>>>> you approach debugging this thing. It may be time-based so I don't >>>>>> think it'll reproduce on your machine out of the box, but who knows. >>>>>> All I know is that, for example, if you add one more sysout before the >>>>>> while loop it suddenly stops reproducing so probably something gets >>>>>> compiled differently... Wild :) >>>>>> >>>>>> Dawid From dawid.weiss at gmail.com Mon Sep 2 02:31:19 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 2 Sep 2013 11:31:19 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> <521BFBD4.7090800@oracle.com> Message-ID: Oh, I forgot to mention - that incremented value cannot be saved to [esp + #136] immediately because there's a value read based on the unincremented value (buffer[upto++]). This is all fine, but the problem is that the incremented spill slot [esp + #144] is never copied to that other spill slot that is read from the other inline. Again -- I have no clue what makes this particular code path so special but I can see it in the debugger clearly. Dawid On Mon, Sep 2, 2013 at 11:17 AM, Dawid Weiss wrote: > I've traced the assembly on a running instance. The problem is quite > interesting -- the code in question is purely computational, I still > don't see how G1GC can be of importance here. In short what's > happening is a method gets inlined in a larger loop more than once and > a field access is placed on the esp spill. The problem is both of > these inlines use a different spill slot and one of the updates is not > properly propagated -- it is saved to one spill slot, then the code > execution flow returns to the top of the loop and another inline reads > a stale value from another spill slot. When you disable escape > analysis everything works as expected. > > The crucial block is: > > 7e25 B1020: # B405 B1021 <- B1017 B1019 Freq: 0.00811184 // XXX > jump from b1017 > 7e25 MOV EBX,[ESP + #136] // ebx = 80e > 7e2c MOV ECX,EBX > 7e2e INC ECX // ecx = 80f, increment. > 7e2f MOV [ESP + #144],ECX // this is the > incremented spill but it never gets propagated to [esp + #136] or > re-read from memory. > 7e36 MOV EBX,[ESP + #132] > 7e3d MOV [EBX + #12],ECX ! Field: > org/apache/lucene/index/ByteSliceReader.upto > 7e40 MOV EBX,[ESP + #152] > 7e47 TEST EBX,EBX > 7e49 Jne B405 P=0.999999 C=-1.000000 // taken, null check > > > The incremented local value of upto gets saved to [ESP + #144] and to > memory but upon reiterating the loop it is re-read from [ESP + #136] > so it looks like a dependency is missed somewhere in the graph causing > escape analysis to fail. > > Ehm, obviously I have no idea how or where to fix this in the JVM code :) > > Full optoassembly dump and annotated opto assembly analysis is here: > http://www.cs.put.poznan.pl/dweiss/tmp/hotspot-bug-analysis.zip > > Let me know if I can do anything else. > > Dawid > > On Tue, Aug 27, 2013 at 9:15 AM, Dawid Weiss wrote: >> Thanks Vladimir. I had the impression I may be looking at the >> interpreter. Just for completeness, I also thought/tried the following >> ways to stop at the jitted code: >> >> 1) call Windows debugger API endpoints from kernel32 -- >> >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx >> >> via JNI/ JNA. This worked surprisingly well -- you can even wait for >> the debugger to attached to the code in a loop, works like a charm. :) >> Although once you break into the debugger I again couldn't make sense >> of the stack -- probably the infrequent call causes a deopt again and >> we're back in the interpreter. >> >> 2) use Unsafe to force a null pointer dereference :) This should send >> a debugger signal, right? I didn't try it though, didn't have the time >> yet. I suspect it may be moved to an infrequent trap too and we're >> back where we started, eh. >> >>> I still did not have time to look on your logs. >> >> No worries, it's been a very very educational experience for me. >> Besides, I used to write tons of assembly (not on x86) and it actually >> feels very good to be back at the assembly mnemonic level ;) >> >> Don't spoil my weekend pet project :) And seriously -- if you want to >> check out those logs let me know in advance and I'll prepare an update >> with hsx-tip if needed. >> >> Dawid >> >> On Tue, Aug 27, 2013 at 3:07 AM, Vladimir Kozlov >> wrote: >>> Dawid, >>> >>> Let it crush with AbortVMOnException (without ShowMessageBoxOnError) and >>> look on call stack in hs_err_pidxxx.log file. Jited code usually have >>> uncommon trap for exceptions so the method most likely was deoptimized and >>> you will see interpeter frames on call stack instead of compiled/jited. >>> There should be deoptimization event listed down in hs_err_pidxxx.log which >>> may say in which address in jited code it hit uncommon trap. You can look on >>> it in optoassembly output. Then during method compilation >>> (-XX:+PrintCompilation -Xbatch -XX:CICompilerCount=1 should give you info >>> when the method is compiled, you can verify it in Compile() by >>> this->method()->print()) in debugger stop in ciEnv::register_method() after >>> call to nmethod::new_nmethod(). nm->insts_begin() shows where instructions >>> start. Add instruction offset from optoassembly and set breakepoint at that >>> address. This way you can stop in jited code. >>> >>> G1 affects inlining since its write barriers code size is larger then other >>> collectors (it has pre and post barriers for oop stores). >>> >>> I still did not have time to look on your logs. >>> >>> Vladimir >>> >>> >>> On 8/26/13 12:56 PM, Dawid Weiss wrote: >>>>> >>>>> An ideal scenario and what I want to achieve is I'd like to stop on an >>>>> assertion somewhere in the jitted code and go back to it to follow the >>>>> execution (so that I can see what code is responsible for the issing >>>> >>>> increment). I'll need to sync this up (manually or otherwise) with the >>>> optoassembly too [...] >>>> >>>> Would somebody be so kind and provide some light on whether the above >>>> is feasible? I'm getting up to speed with visual studio -- haven't >>>> used assembly-level debugging in a longer while -- but I'm having >>>> troubles connecting the dots with verbose optoassembly output (the >>>> addresses don't seem to match). Thanks and again, apologies if it's >>>> something trivial but I couldn't find any helpful resources on the >>>> net. >>>> >>>> Dawid >>>> >>>> On Sun, Aug 25, 2013 at 9:43 PM, Dawid Weiss >>>> wrote: >>>>> >>>>> I know why the assertion is hit. I still don't know (and probably >>>>> won't figure it out) why it is so difficult to reproduce or which >>>>> optimization leads to it. >>>>> >>>>> In short, the following code in ByteSliceReader#readByte: >>>>> >>>>> public byte readByte() { >>>>> assert !eof(); >>>>> assert upto <= limit; >>>>> if (upto == limit) { >>>>> nextSlice(); >>>>> } >>>>> return buffer[upto++]; >>>>> } >>>>> >>>>> is inlined in a number of places. If I include: >>>>> >>>>> public byte readByte() { >>>>> assert !eof(); >>>>> assert upto <= limit; >>>>> if (upto == limit) { >>>>> nextSlice(); >>>>> baz = upto; >>>>> } >>>>> return buffer[upto++]; >>>>> } >>>>> static int baz; >>>>> >>>>> I see a number of assignments to 'baz'. This is because methods like >>>>> readVInt fork out many conditional branches, as in: >>>>> >>>>> public int readVInt() throws IOException { >>>>> byte b = readByte(); >>>>> if (b >= 0) return b; >>>>> int i = b & 0x7F; >>>>> b = readByte(); >>>>> i |= (b & 0x7F) << 7; >>>>> if (b >= 0) return i; >>>>> b = readByte(); >>>>> i |= (b & 0x7F) << 14; >>>>> if (b >= 0) return i; >>>>> b = readByte(); >>>>> i |= (b & 0x7F) << 21; >>>>> if (b >= 0) return i; >>>>> b = readByte(); >>>>> // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste >>>>> errors: >>>>> i |= (b & 0x0F) << 28; >>>>> if ((b & 0xF0) == 0) return i; >>>>> throw new IOException("Invalid vInt detected (too many bits)"); >>>>> } >>>>> >>>>> One of these executions (when upto == limit, and possibly with some >>>>> other upper condition) leads to missing increment on buffer[upto++] -- >>>>> upto remains unmodified (but the value at buffer[upto] is returned >>>>> properly). Because upto is moved to a register in many of those >>>>> inlined methods I suspect either the register may be incremented and >>>>> not saved or the increment may be removed due to some local escape >>>>> analysis magic (that has to be incorrect, obviously). How G1GC >>>>> interacts with all this (remember, it only happens with G1GC) I have >>>>> no clue. >>>>> >>>>> Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't >>>>> make much sense of it. I also dug into some of the opto assembly >>>>> branches trying to map them back into the original bytecode, but it's >>>>> a very long process -- had to map PcDesc manually to the assembly >>>>> offset, then go to bytecode again. Then I fired visual studio and >>>>> halted it like Vladimir mentioned: >>>>> -XX:AbortVMOnException=java.lang.AssertionError >>>>> -XX:+ShowMessageBoxOnError >>>>> >>>>> Once I attach to the halted JVM I "break all" and I see the reported >>>>> thread's stack trace halted inside ntdll (with the closest JVM frame >>>>> stopped at get_deopt_original_pc). The frames below it don't seem to >>>>> make much sense to me -- they don't seem to point to any addresses >>>>> reported in the compilation log (PcDesc clauses). I'm a complete >>>>> newbie to this, so I apologize if it's a lame question, but how can I >>>>> find out which part of the original jitted code this assertion was >>>>> invoked from? >>>>> >>>>> An ideal scenario and what I want to achieve is I'd like to stop on an >>>>> assertion somewhere in the jitted code and go back to it to follow the >>>>> execution (so that I can see what code is responsible for the missing >>>>> increment). I'll need to sync this up (manually or otherwise) with the >>>>> optoassembly too, otherwise I'll probably lose any remaining hair >>>>> trying to figure out what's what :) >>>>> >>>>> A hint (or any other pointer; RTFM) would be very welcome. >>>>> >>>>> Dawid >>>>> >>>>> >>>>> On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss >>>>> wrote: >>>>>> >>>>>> One follow-up with respect to those encoded integers -- I swapped the >>>>>> correct and incorrect sequence in my last e-mail, sorry. I then also >>>>>> added a sysout here: >>>>>> >>>>>> @@ -451,6 +453,7 @@ >>>>>> termFreq = 1; >>>>>> } else { >>>>>> termFreq = freq.readVInt(); >>>>>> + System.err.print("# (tf): " + termFreq + " "); >>>>>> } >>>>>> } >>>>>> >>>>>> With this the assertion is no longer hit but it shows where the >>>>>> difference in numbers comes from: >>>>>> >>>>>> Correct sequence is: >>>>>> >>>>>> # (eof) >>>>>> # (code): 0 >>>>>> # (tf): 3 >>>>>> # (code): 4 >>>>>> # (tf): 3 >>>>>> # (code): 2 >>>>>> # (tf): 5 >>>>>> # (code): 2 >>>>>> # (tf): 2 >>>>>> # (code): 3 >>>>>> # (code): 5 >>>>>> # (code): 2 >>>>>> >>>>>> And the incorrect, assertion-hit run shows: >>>>>> >>>>>> # (eof) >>>>>> # (code): 0 >>>>>> # (code): 3 >>>>>> # (code): 4 >>>>>> # (code): 3 >>>>>> # (code): 2 >>>>>> # (code): 5 >>>>>> # (code): 2 >>>>>> # (code): 2 >>>>>> # (code): 3 >>>>>> >>>>>> So there's something odd happening after the first readvint which >>>>>> returns 0 -- the next number that should be read by: >>>>>> >>>>>> termFreq = freq.readVInt(); >>>>>> >>>>>> is re-read as the next code. >>>>>> >>>>>> Dawid >>>>>> >>>>>> >>>>>> On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss >>>>>> wrote: >>>>>>> >>>>>>> Thanks for comments guys. >>>>>>> >>>>>>>> It is great that you can build fastdebug VM. I assume that if I give >>>>>>>> you a >>>>>>>> patch to try you can also build with it. >>>>>>> >>>>>>> >>>>>>> Yes, absolutely. >>>>>>> >>>>>>>> First, you can run with next options and then send zipped output >>>>>>>> (related >>>>>>>> part before the method compilation and optoassembler output, don't use >>>>>>>> hsdis >>>>>>>> for that) and hs_err file when test fails: >>>>>>> >>>>>>> >>>>>>> I did that. Used the options you requested -- a full log of all I did >>>>>>> is included in the ZIP file here: >>>>>>> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >>>>>>> >>>>>>> Cat debug-files\debug-log.txt. There are several runs included in that >>>>>>> ZIP file, in short: >>>>>>> >>>>>>> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >>>>>>> debug-log.txt): >>>>>>> 001-no-abort-on-assertion >>>>>>> 002-no-abort-on-assertion >>>>>>> >>>>>>> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >>>>>>> 003-with-abort-on-assertion >>>>>>> 004-with-abort-on-assertion >>>>>>> >>>>>>> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >>>>>>> 005-hsx-tip >>>>>>> 006-hsx-tip >>>>>>> >>>>>>> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >>>>>>> build, so only compilation logs available). >>>>>>> 007-excluded-readvint >>>>>>> >>>>>>>> Looking on java code in FreqProxTermsWriterPerField::flush() and based >>>>>>>> on >>>>>>>> LUCENE-5168 report generated code somehow missed EOF check. Am I >>>>>>>> right? This >>>>>>>> is why the Assert is thrown? >>>>>>> >>>>>>> >>>>>>> It's not the only method it trips on. Depending on the seed the >>>>>>> problem shows up in different places. For the dumps I included the >>>>>>> issue seems to be here: >>>>>>> >>>>>>>> } else { >>>>>>>> final int code = freq.readVInt(); >>>>>>>> if (!readTermFreq) { >>>>>>>> docID += code; >>>>>>>> termFreq = -1; >>>>>>> >>>>>>> >>>>>>> If I add sysouts as in: >>>>>>> >>>>>>> Index: >>>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>>> =================================================================== >>>>>>> --- >>>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>>> (revision 1512807) >>>>>>> +++ >>>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>>> (working copy) >>>>>>> @@ -427,6 +427,7 @@ >>>>>>> //System.out.println(" cycle"); >>>>>>> final int termFreq; >>>>>>> if (freq.eof()) { >>>>>>> + System.err.print("# (eof)"); >>>>>>> if (postings.lastDocCodes[termID] != -1) { >>>>>>> // Return last doc >>>>>>> docID = postings.lastDocIDs[termID]; >>>>>>> @@ -442,6 +443,7 @@ >>>>>>> } >>>>>>> } else { >>>>>>> final int code = freq.readVInt(); >>>>>>> + System.err.print("# (code): " + code + " "); >>>>>>> if (!readTermFreq) { >>>>>>> docID += code; >>>>>>> termFreq = -1; >>>>>>> >>>>>>> then for a constant seed you'll get an identical sequence of values. >>>>>>> Once the assertion hits though, the sequence deviates. Comparing a >>>>>>> passing run (excluding readvint) and a failing run I get a lot of >>>>>>> initial aligned outputs and then a deviation: >>>>>>> >>>>>>> (correct run): >>>>>>> # (eof) >>>>>>> # (eof) >>>>>>> # (eof) >>>>>>> # (code): 0 >>>>>>> # (code): 3 >>>>>>> # (code): 4 >>>>>>> # (code): 3 >>>>>>> >>>>>>> (incorrect run): >>>>>>> # (eof) >>>>>>> # (eof) >>>>>>> # (eof) >>>>>>> # (code): 0 >>>>>>> # (code): 4 <- wtf? >>>>>>> # (code): 2 >>>>>>> # (code): 2 >>>>>>> >>>>>>> How can a variable encoded integer be misinterpreted from 3 to 4 is >>>>>>> beyond me, sorry. But it's not an EOF condition I think, at least the >>>>>>> deviation happens where the original run had was entering (code) >>>>>>> branch. >>>>>>> >>>>>>>> Could you also send latest version of FreqProxTermsWriterPerField.java >>>>>>>> you >>>>>>>> are testing? >>>>>>> >>>>>>> >>>>>>> I'm testing against a fixed branch (the info is included in >>>>>>> debug-log.txt). >>>>>>> >>>>>>> If there's anything else I can do, let me know. I'm also curious how >>>>>>> you approach debugging this thing. It may be time-based so I don't >>>>>>> think it'll reproduce on your machine out of the box, but who knows. >>>>>>> All I know is that, for example, if you add one more sysout before the >>>>>>> while loop it suddenly stops reproducing so probably something gets >>>>>>> compiled differently... Wild :) >>>>>>> >>>>>>> Dawid From frederic.parain at oracle.com Mon Sep 2 05:15:16 2013 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 02 Sep 2013 14:15:16 +0200 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <52248154.3010104@oracle.com> Vote: yes Fred On 29/08/2013 20:36, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From john.coomes at oracle.com Tue Sep 3 23:04:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 04 Sep 2013 06:04:11 +0000 Subject: hg: hsx/hotspot-main: 5 new changesets Message-ID: <20130904060412.969E062512@hg.openjdk.java.net> Changeset: c8da1b6a9762 Author: mduigou Date: 2013-08-20 17:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c8da1b6a9762 8023433: Improve 'make help' Reviewed-by: tbell ! NewMakefile.gmk Changeset: f643fee2b40f Author: mduigou Date: 2013-08-26 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f643fee2b40f 8023491: Remove target names from test/Makefile and defer to sub-repo makefiles. Reviewed-by: erikj ! common/makefiles/Main.gmk ! test/Makefile Changeset: 163091288aeb Author: lana Date: 2013-08-26 14:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/163091288aeb Merge ! common/makefiles/Main.gmk Changeset: 51a61778a99d Author: mduigou Date: 2013-08-29 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/51a61778a99d 8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output. Reviewed-by: erikj, vromero, henryjen ! test/Makefile Changeset: 4ac867c44467 Author: lana Date: 2013-08-29 16:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4ac867c44467 Merge From john.coomes at oracle.com Tue Sep 3 23:04:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 04 Sep 2013 06:04:34 +0000 Subject: hg: hsx/hotspot-main/jaxws: 4 new changesets Message-ID: <20130904060446.D4CDD62513@hg.openjdk.java.net> Changeset: b99d7e355d4b Author: mkos Date: 2013-08-23 09:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b99d7e355d4b 8022885: Update JAX-WS RI integration to 2.2.9-b14140 8013016: Rebase 8009009 against the latest jdk8/jaxws Reviewed-by: alanb, chegar ! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeRef.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/package-info.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/EditDistance.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDEventListener.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDHandlerBase.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDParser.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EndOfInputException.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EntityDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/ExternalEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InputEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InternalEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/MessageCatalog.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/Resolver.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/SimpleHashtable.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlChars.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlNames.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlReader.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/package.html ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/resources/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreatorProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AttributesHolder.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/FragmentedArray.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferException.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferMark.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferResult.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferSource.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/DefaultWithLexicalHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Features.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Properties.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/ersSet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/group.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/JAXPParser.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/XSOMParser.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java ! src/share/jaxws_classes/javax/xml/bind/Binder.java ! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java ! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java ! src/share/jaxws_classes/javax/xml/bind/Element.java ! src/share/jaxws_classes/javax/xml/bind/GetPropertyAction.java ! src/share/jaxws_classes/javax/xml/bind/JAXB.java ! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java ! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java ! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java ! src/share/jaxws_classes/javax/xml/bind/MarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Messages.java ! src/share/jaxws_classes/javax/xml/bind/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java ! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PropertyException.java ! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java ! src/share/jaxws_classes/javax/xml/bind/ValidationException.java ! src/share/jaxws_classes/javax/xml/bind/Validator.java ! src/share/jaxws_classes/javax/xml/bind/WhiteSpaceProcessor.java ! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html ! src/share/jaxws_classes/javax/xml/bind/annotation/package.html ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/package.html ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.java ! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/package.html ! src/share/jaxws_classes/javax/xml/bind/package.html ! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java ! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java ! src/share/jaxws_classes/javax/xml/bind/util/Messages.java ! src/share/jaxws_classes/javax/xml/bind/util/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java ! src/share/jaxws_classes/javax/xml/bind/util/package.html Changeset: d8593d8581df Author: mkos Date: 2013-08-23 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d8593d8581df 8023636: Missing files from 8022885 Reviewed-by: alanb, chegar + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/StreamingSOAP.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamespaceContextExAdaper.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLReaderComposite.java Changeset: 533c1032337c Author: lana Date: 2013-08-26 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/533c1032337c Merge Changeset: 6908370afe83 Author: lana Date: 2013-08-29 16:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/6908370afe83 Merge From john.coomes at oracle.com Tue Sep 3 23:06:05 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 04 Sep 2013 06:06:05 +0000 Subject: hg: hsx/hotspot-main/jdk: 48 new changesets Message-ID: <20130904061706.0880A62514@hg.openjdk.java.net> Changeset: eb18a483e772 Author: alanb Date: 2013-08-21 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eb18a483e772 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile Reviewed-by: lancea, mduigou ! test/TEST.ROOT + test/TEST.groups Changeset: 68be998c2596 Author: egahlin Date: 2013-08-19 12:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/68be998c2596 6358357: Division by zero in Threads tab when shrinking jconsole window Reviewed-by: mchung, leifs, jbachorik ! src/share/classes/sun/tools/jconsole/Plotter.java Changeset: bddf55211ed8 Author: egahlin Date: 2013-08-19 16:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bddf55211ed8 6417721: Thread list should not allow multiple selection Reviewed-by: alanb, jbachorik, sjiang ! src/share/classes/sun/tools/jconsole/ThreadTab.java Changeset: 2636d337a1ed Author: egahlin Date: 2013-08-19 16:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2636d337a1ed 6800801: NPE in JConsole when using Nimbus L&F Reviewed-by: alanb, sjiang ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/VMPanel.java Changeset: ba943fc47fc8 Author: egahlin Date: 2013-08-19 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba943fc47fc8 7042707: Un-needed mnemonic in JConsole resource file Reviewed-by: mfang, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 3b8fed46b2a8 Author: dholmes Date: 2013-08-21 05:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b8fed46b2a8 8023460: OPENJDK build fails due to missing jfr.jar Reviewed-by: alanb ! makefiles/Profiles.gmk Changeset: 8996f47f738d Author: sla Date: 2013-08-21 17:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8996f47f738d 8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt Reviewed-by: chegar, mgronlun ! test/ProblemList.txt Changeset: fad3b6673159 Author: mduigou Date: 2013-08-21 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fad3b6673159 8023306: Add replace() implementations to TreeMap Reviewed-by: psandoz, alanb, chegar, bpb ! src/share/classes/java/util/TreeMap.java Changeset: 91a31c77be5b Author: mduigou Date: 2013-08-21 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/91a31c77be5b 8023395: Remove sun.misc.Sort and sun.misc.Compare Reviewed-by: alanb, smarks, darcy, mr - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 60891d90327f Author: henryjen Date: 2013-08-20 14:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60891d90327f 8016846: Pattern.splitAsStream tests required Reviewed-by: alanb, psandoz Contributed-by: Ben Evans + test/java/util/regex/PatternTest.java Changeset: ec827a62070a Author: xuelei Date: 2013-08-21 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ec827a62070a 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java Changeset: a0896634ab46 Author: sla Date: 2013-08-22 08:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a0896634ab46 8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails Reviewed-by: ysr ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java Changeset: b7c4094be729 Author: darcy Date: 2013-08-22 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b7c4094be729 8023587: Fix lone remaining doclint issue in java.util.regex Reviewed-by: jjg ! src/share/classes/java/util/regex/Pattern.java Changeset: 8a7d9cc2f41c Author: dxu Date: 2013-08-22 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a7d9cc2f41c 8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details Reviewed-by: alanb ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java Changeset: 2281a7f79738 Author: plevart Date: 2013-08-20 14:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2281a7f79738 8022721: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition Reviewed-by: alanb, jfranck ! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java Changeset: 7496ec8bab76 Author: smarks Date: 2013-08-22 15:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7496ec8bab76 8022445: fix RMISocketFactory example to avoid using localhost Reviewed-by: chegar, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java Changeset: 7b6211cd8d76 Author: egahlin Date: 2013-08-21 17:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7b6211cd8d76 6417649: -interval=0 is accepted and jconsole doesn't update window content at all Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/JConsole.java Changeset: 77a32e5df365 Author: egahlin Date: 2013-08-21 17:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77a32e5df365 6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties Changeset: 223be1d3494f Author: bpb Date: 2013-08-22 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/223be1d3494f 6470700: Math.random() / Math.initRNG() uses "double checked locking" Summary: Replace class Random variable with a static final holder class Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: 4ef82445ea20 Author: dfuchs Date: 2013-08-23 20:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4ef82445ea20 8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle Reviewed-by: mchung, lancea ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getLogger/TestLogger.java + test/java/util/logging/Logger/getLogger/testlogger/MyResource.java Changeset: 216a4b93cee8 Author: bpb Date: 2013-08-23 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/216a4b93cee8 6378503: In java.math.BigDecimal, division by one returns zero 6446965: Using BigDecimal.divideToIntegralValue with extreme scales can lead to an incorrect result Summary: Fix overflow of ints and ensure appropriate values passed to checkScaleNonZero() Reviewed-by: darcy, martin Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigDecimal/IntegralDivisionTests.java Changeset: 0ee3b995d63b Author: alanb Date: 2013-08-26 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ee3b995d63b 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/file/WatchService/SensitivityModifier.java Changeset: 67a1a031876a Author: igerasim Date: 2013-08-25 23:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/67a1a031876a 7129312: BufferedInputStream calculates negative array size with large streams and mark Reviewed-by: alanb ! src/share/classes/java/io/BufferedInputStream.java + test/java/io/BufferedInputStream/LargeCopyWithMark.java Changeset: 6917c114b197 Author: jfranck Date: 2013-08-26 13:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6917c114b197 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases Reviewed-by: darcy, vromero, psandoz ! src/share/classes/java/lang/Class.java ! test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java Changeset: 8a36fc7f494c Author: shade Date: 2013-08-26 17:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a36fc7f494c 8023234: StampedLock serializes readers on writer unlock Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock Reviewed-by: martin, shade Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java Changeset: 07585a2483fa Author: rriggs Date: 2013-08-26 11:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/07585a2483fa 8011944: Sort fails with ArrayIndexOutOfBoundsException Summary: Increase the size of pending stack and add test cases Reviewed-by: alanb ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/TimSort.java + test/java/util/Arrays/TimSortStackSize.java Changeset: 92a66af7f834 Author: igerasim Date: 2013-08-26 18:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92a66af7f834 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions Reviewed-by: alanb, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 5ce9025c9e1a Author: psandoz Date: 2013-08-26 22:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ce9025c9e1a 8020292: j.u.SplittableRandom Reviewed-by: mduigou Contributed-by: Guy Steele , Doug Lea
, Brian Goetz , Paul Sandoz + src/share/classes/java/util/SplittableRandom.java + test/java/util/SplittableRandom/SplittableRandomTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java Changeset: 35c1609d9488 Author: henryjen Date: 2013-08-09 09:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/35c1609d9488 8023681: Fix raw type warning caused by Sink Reviewed-by: mduigou, briangoetz ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DistinctOps.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/SliceOps.java ! src/share/classes/java/util/stream/SortedOps.java Changeset: 9586ca82bd8b Author: bpittore Date: 2013-08-26 11:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9586ca82bd8b 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: alanb, sspitsyn, bobv, coleenp ! src/share/classes/com/sun/tools/attach/VirtualMachine.java Changeset: c58e39bb5d62 Author: lana Date: 2013-08-26 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c58e39bb5d62 Merge Changeset: 6cdc679e3412 Author: lana Date: 2013-08-26 22:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6cdc679e3412 Merge Changeset: ca53110f1c74 Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ca53110f1c74 8015669: KerberosPrincipal::equals should ignore name-type Reviewed-by: mullan ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java + test/sun/security/krb5/auto/KPEquals.java Changeset: 4bddc344848e Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bddc344848e 8022761: regression: SecurityException is NOT thrown while trying to pack a wrongly signed Indexed Jar file Reviewed-by: sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/sun/security/tools/jarsigner/jvindex.sh Changeset: 134283a88499 Author: mullan Date: 2013-08-27 10:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/134283a88499 8023769: JDK-8016850 broke the old build Summary: remove files that were moved/removed from com/sun/security/auth/FILES_java.gmk Reviewed-by: chegar, xuelei ! make/com/sun/security/auth/FILES_java.gmk Changeset: 6a1bfcde4d4d Author: mullan Date: 2013-08-27 12:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a1bfcde4d4d 8019830: Add com.sun.media.sound to the list of restricted package Reviewed-by: vinnie ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 3575263eefab Author: mullan Date: 2013-08-27 12:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3575263eefab Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 51151b440e95 Author: darcy Date: 2013-08-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51151b440e95 8023827: Fix doclint issues in javax.net.ssl Reviewed-by: wetmore, xuelei ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/X509KeyManager.java Changeset: ade440668f94 Author: henryjen Date: 2013-08-26 22:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ade440668f94 8023275: Wrapping collections should override default methods Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/Collections.java + test/java/util/Collections/Wrappers.java Changeset: 3f6777cbfe69 Author: sherman Date: 2013-08-27 12:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f6777cbfe69 8023647: "abc1c".matches("(\\w)+1\\1")) returns false Summary: to correct the wrong GroupCurly group index backoff code Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: be2d25a277a7 Author: henryjen Date: 2013-08-21 20:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be2d25a277a7 8023528: Rename Comparator combinators to disambiguate overloading methods Reviewed-by: mduigou, smarks ! src/share/classes/java/util/Comparator.java ! test/java/util/Comparator/BasicTest.java ! test/java/util/Map/EntryComparators.java ! test/java/util/function/BinaryOperator/BasicTest.java Changeset: 2efa310226f7 Author: alanb Date: 2013-08-28 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2efa310226f7 8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException Reviewed-by: wetmore, alanb Contributed-by: martinrb at google.com ! src/share/classes/java/lang/ProcessBuilder.java Changeset: 378acd4d03c8 Author: alanb Date: 2013-08-28 15:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/378acd4d03c8 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil Reviewed-by: chegar ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/KQueue.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/DatagramDispatcher.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/FileKey.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: 690b2931baef Author: sherman Date: 2013-08-28 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/690b2931baef 8023713: ZipFileSystem crashes on old zip file Summary: to handle extra data field copy correctly even the extra data does not follow the spec Reviewed-by: alanb, martin, chegar ! src/share/classes/java/util/zip/ZipOutputStream.java ! test/java/util/zip/TestExtraTime.java Changeset: b1f41565b806 Author: psandoz Date: 2013-08-28 22:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b1f41565b806 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom Reviewed-by: mduigou Contributed-by: Doug Lea
, Paul Sandoz ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/Random/RandomStreamTest.java + test/java/util/Random/RandomTest.java ! test/java/util/SplittableRandom/SplittableRandomTest.java + test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java Changeset: 779ff9f3b2e3 Author: sla Date: 2013-08-29 11:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/779ff9f3b2e3 8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes ! src/share/back/SDE.c ! src/share/native/common/check_code.c Changeset: 5bf4f2eeee85 Author: dxu Date: 2013-08-29 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bf4f2eeee85 4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links Summary: Exclude the possible usage of linked files or directories in the test Reviewed-by: alanb ! test/java/io/pathNames/General.java Changeset: c817276bd870 Author: lana Date: 2013-08-29 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c817276bd870 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java From john.coomes at oracle.com Tue Sep 3 23:19:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 04 Sep 2013 06:19:14 +0000 Subject: hg: hsx/hotspot-main/langtools: 21 new changesets Message-ID: <20130904062032.F194462515@hg.openjdk.java.net> Changeset: 7de231613e4a Author: jjg Date: 2013-08-21 16:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7de231613e4a 8023515: import type-annotations updates Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java + test/tools/javac/annotations/typeAnnotations/failures/T8020715.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java + test/tools/javac/tree/TypeAnnotationsPretty.java Changeset: 2068190f8ac2 Author: emc Date: 2013-08-21 20:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2068190f8ac2 7118412: Shadowing of type-variables vs. member types 4987840: What is the scope of an annotation? Summary: Fixed issue with shadowing of type names. Reviewed-by: jjg, abuckley, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 57e1266527dd Author: jjg Date: 2013-08-21 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/57e1266527dd 8022287: javac.sym.Profiles uses a static Map when it should not Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/sym/Profiles.java + test/tools/javac/profiles/ProfileTest.java Changeset: eebb29618f50 Author: emc Date: 2013-08-21 20:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/eebb29618f50 8023520: Add missing test for JDK-7118412 Summary: The test for JDK-7118412 was dropped from the changeset in a merging accident. Reviewed-by: jjg + test/tools/javac/7118412/ShadowingTest.java Changeset: 7a4717f3ea7b Author: vromero Date: 2013-08-22 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7a4717f3ea7b 8022316: Generic throws, overriding and method reference Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out Changeset: 25aaff78d754 Author: vromero Date: 2013-08-22 13:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/25aaff78d754 8023112: javac should not use lazy constant evaluation approach for method references Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java Changeset: 1ab22e60a738 Author: emc Date: 2013-08-22 12:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1ab22e60a738 8020745: Suspicious MethodParameters attribute generated for local classes capturing local variables Summary: Corrected an error in a previous patch that caused captured locals to be added to the beginning, not the end of a parameter list. Reviewed-by: jjg, mcimadamore, ksrini, abuckley ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java - test/tools/javac/8015701/AnonymousParameters.java + test/tools/javac/MethodParameters/CaptureTest.java Changeset: b77381d99056 Author: jjg Date: 2013-08-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b77381d99056 8022173: Relax some warnings in doclint Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/ListTagsTest.java ! test/tools/doclint/html/OtherTagsTest.java ! test/tools/doclint/html/OtherTagsTest.out ! test/tools/doclint/html/TableTagsTest.java Changeset: 60f156c653d3 Author: jjg Date: 2013-08-26 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/60f156c653d3 8023701: Fix badly named test Reviewed-by: bpatel - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java + test/com/sun/javadoc/testNavigation/TestNavigation.java + test/com/sun/javadoc/testNavigation/pkg/A.java + test/com/sun/javadoc/testNavigation/pkg/C.java + test/com/sun/javadoc/testNavigation/pkg/E.java + test/com/sun/javadoc/testNavigation/pkg/I.java Changeset: 7bf6313e1ced Author: jjg Date: 2013-08-26 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7bf6313e1ced 8023768: Use the unannotatedType in cyclicity checks. Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java Changeset: 00ca54ceca1b Author: lana Date: 2013-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/00ca54ceca1b Merge Changeset: cc3fb73f5e08 Author: lana Date: 2013-08-26 22:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cc3fb73f5e08 Merge Changeset: 7fb27bc201cc Author: bpatel Date: 2013-08-27 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7fb27bc201cc 7052170: javadoc -charset option generates wrong meta tag Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java + test/com/sun/javadoc/testCharset/TestCharset.java + test/com/sun/javadoc/testCharset/pkg/Foo.java Changeset: 662a5188bded Author: darcy Date: 2013-08-27 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/662a5188bded 8023826: Typo in warning about obsolete source / target values Reviewed-by: jjg, wmdietl ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 7de7100c30ce Author: henryjen Date: 2013-08-28 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7de7100c30ce 8014566: Remove @ignore tags from MethodReference66 and InInterface when 8013875 is fixed Reviewed-by: briangoetz, jjg ! test/tools/javac/lambda/MethodReference66.java ! test/tools/javac/lambda/lambdaExecution/InInterface.java Changeset: 189942cdf585 Author: jjg Date: 2013-08-28 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/189942cdf585 8010310: [javadoc] Error processing sources with -private Reviewed-by: vromero, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java + test/tools/javadoc/nonConstExprs/Test.java Changeset: 0e6577980181 Author: jjg Date: 2013-08-29 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0e6577980181 8001669: javadoc internal DocletAbortException should set cause when appropriate Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.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/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.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/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.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/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: b0b25c1f6cbd Author: jjg Date: 2013-08-29 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b0b25c1f6cbd 8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only Reviewed-by: darcy ! test/tools/javac/tree/TypeAnnotationsPretty.java Changeset: 9c0e192c0926 Author: jjg Date: 2013-08-29 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9c0e192c0926 8013384: Potential infinite loop in javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java Changeset: 96b6865eda94 Author: jjg Date: 2013-08-29 12:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/96b6865eda94 8022744: javac -Xpkginfo command's documentation is sparse Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: fcd768844b99 Author: lana Date: 2013-08-29 16:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fcd768844b99 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java From john.coomes at oracle.com Tue Sep 3 23:20:57 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 04 Sep 2013 06:20:57 +0000 Subject: hg: hsx/hotspot-main/nashorn: 24 new changesets Message-ID: <20130904062122.25F1062516@hg.openjdk.java.net> Changeset: dbb0a20a6f27 Author: attila Date: 2013-08-21 13:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/dbb0a20a6f27 8023373: allow super invocation for adapters Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + test/script/basic/JDK-8023373.js + test/script/basic/JDK-8023373.js.EXPECTED Changeset: dc322503ce36 Author: attila Date: 2013-08-21 13:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/dc322503ce36 8022903: Enhance for-in and for-each for Lists and Maps Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8022903.js + test/script/basic/JDK-8022903.js.EXPECTED Changeset: b7c04b3b01a7 Author: sundar Date: 2013-08-21 17:28 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b7c04b3b01a7 8023368: Instance __proto__ property should exist and be writable. Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8023368.js + test/script/basic/JDK-8023368.js.EXPECTED + test/script/basic/JDK-8023368_2.js + test/script/basic/JDK-8023368_2.js.EXPECTED + test/script/basic/circular_proto.js + test/script/basic/circular_proto.js.EXPECTED + test/script/basic/mirror_proto_assign.js + test/script/basic/mirror_proto_assign.js.EXPECTED + test/script/basic/nonextensible_proto_assign.js + test/script/basic/nonextensible_proto_assign.js.EXPECTED Changeset: 54f60d91024c Author: sundar Date: 2013-08-22 18:46 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/54f60d91024c 8023551: Mirror functions can not be invoked using invokeMethod, invokeFunction Reviewed-by: attila, jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + test/script/basic/JDK-8023551.js + test/script/basic/JDK-8023551.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 8ad9bcb04e6d Author: hannesw Date: 2013-08-22 17:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8ad9bcb04e6d 8023531: new RegExp('').toString() should return '/(?:)/' Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/regexp/RegExp.java + test/script/basic/JDK-8023531.js Changeset: c5c5ab3f420a Author: jlaskey Date: 2013-08-22 13:51 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c5c5ab3f420a 8023228: Debugger information gather is too slow. Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/DebuggerSupport.java Changeset: 5a1e07b9a3cd Author: sundar Date: 2013-08-22 22:32 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5a1e07b9a3cd 8023560: Arbitrary javax.script.Bindings objects as ENGINE_SCOPE objects are not handled as expected. Reviewed-by: jlaskey, lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: d82ac93aa55c Author: sundar Date: 2013-08-23 16:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d82ac93aa55c 8023631: engine.js init script should be loaded into every global instance created by engines Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + test/src/jdk/nashorn/api/scripting/InvocableTest.java + test/src/jdk/nashorn/api/scripting/ScopeTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 6b6a8fc714a9 Author: lagergren Date: 2013-08-23 12:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6b6a8fc714a9 8023453: --log=attr did not unindent identNodes Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java Changeset: 4dcd5a22fdd3 Author: lagergren Date: 2013-08-23 12:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4dcd5a22fdd3 Merge Changeset: f18f2ce1b2dc Author: attila Date: 2013-08-23 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f18f2ce1b2dc 8023630: Implement Java.super() as the preferred way to call super methods Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java + src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapter.java + src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java + test/script/basic/JDK-8023630.js + test/script/basic/JDK-8023630.js.EXPECTED ! test/script/basic/NASHORN-397.js Changeset: 2ce55025a37d Author: sundar Date: 2013-08-23 16:44 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2ce55025a37d Merge Changeset: a18f92a0a910 Author: lana Date: 2013-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a18f92a0a910 Merge Changeset: badc919cd621 Author: lagergren Date: 2013-08-23 14:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/badc919cd621 8023550: -d option was broken for any dir but '.'. Fixed Java warnings. Reviewed-by: jlaskey, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java ! src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Region.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java ! src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java ! tools/fxshell/jdk/nashorn/tools/FXShell.java Changeset: e2d94d032760 Author: jlaskey Date: 2013-08-23 09:56 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e2d94d032760 8020946: TokenType#toString returned null Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/parser/TokenType.java Changeset: eb7b8340ce3a Author: lagergren Date: 2013-08-23 15:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/eb7b8340ce3a 8023454: Updated DEVELOPER_README and command line flags, ensuring that undocumented flags that aren't guaranteed to work (disabled by default) and that are work in progress show up with an EXPERIMENTAL tag. Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/runtime/resources/Options.properties Changeset: 12820c8d0a5d Author: jlaskey Date: 2013-08-23 12:20 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/12820c8d0a5d 8019987: String trimRight and trimLeft could be defined Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/JDK-8019987.js Changeset: c19c66e661a9 Author: hannesw Date: 2013-08-26 15:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c19c66e661a9 8023650: Regexp m flag does not recognize CRNL or CR Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Config.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/JDK-8023650.js Changeset: 99e48c76d11f Author: jlaskey Date: 2013-08-26 15:33 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/99e48c76d11f 8023721: Simplify eval in DebuggerSupport. Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java Changeset: 3bd077423a08 Author: sundar Date: 2013-08-27 15:54 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3bd077423a08 8022773: ScriptEngineTest.printManyTest fails Reviewed-by: lagergren, attila ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 47f0a4c4b729 Author: attila Date: 2013-08-27 13:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/47f0a4c4b729 8023780: Gracefully handle @CS methods while binding bean properties Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/basic/JDK-8023780.js + test/script/basic/JDK-8023780.js.EXPECTED Changeset: bda0e89f88ae Author: sundar Date: 2013-08-27 18:57 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bda0e89f88ae 8023784: Object.prototype.toString should contain the class name for all instances Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8023784.js + test/script/basic/JDK-8023784.js.EXPECTED ! test/script/basic/NASHORN-377.js.EXPECTED Changeset: 101606d3eb84 Author: sundar Date: 2013-08-27 19:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/101606d3eb84 Merge Changeset: bf70cbd2c836 Author: lana Date: 2013-08-29 16:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bf70cbd2c836 Merge From volker.simonis at gmail.com Wed Sep 4 08:33:37 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Sep 2013 17:33:37 +0200 Subject: RFR (XL): 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles Message-ID: Hi all (sorry, the first mail was only sent to ppc-aix-port-dev), this webrev contains the necessary Makefiles for building the HotSpot on AIX: http://cr.openjdk.java.net/~simonis/webrevs/8023034/ Most of the files are based on their corresponding Linux counterparts. Notice that although this RFR is flagged 'XL', the changes to shared code are really tiny and only in make/defs.make where AIX is added to the chain of not-Windows platforms. Of course the build itself will be possible only after the next change ("8023038: PPC64 (part 15): Platform files for AIX/PPC64 support") which will finally introduce the AIX platform source files. So not much to test here - just read and enjoy:) Thank you and best regards, Volker From volker.simonis at gmail.com Wed Sep 4 08:34:39 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Sep 2013 17:34:39 +0200 Subject: RFR (XL): 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support Message-ID: Hi all (sorry, the first mail was only sent to ppc-aix-port-dev), this change finally contains the basic AIX platform source files: http://cr.openjdk.java.net/~simonis/webrevs/8023038 Together with the previous change ("8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles") it enables the build of an interpreter-only HotSpot VM on AIX. Assuming you have xlC and the needed tools like GNU make in your path you can build it with the following command line from within the hotspot/make directory: make ALT_BOOTDIR= ALT_OUTPUTDIR=/tmp/stage-opt-core/ ARCH_DATA_MODEL=64 VERBOSE=true CC_INTERP=true OPENJDK=true HOTSPOT_BUILD_JOBS=8 JVM_VARIANT_CORE=true all_productcore Notice that although this change is flagged 'XL' it only contains platform dependent files in 'src/os/aix/', 'src/os_cpu/aix_ppc' and 'src/share/vm/utilities/globalDefinitions_xlc.hpp' and doesn't affect the current Oracle platforms at all. Thank you and best regards, Volker From vladimir.kozlov at oracle.com Wed Sep 4 09:41:41 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 04 Sep 2013 09:41:41 -0700 Subject: RFR (XL): 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles In-Reply-To: References: Message-ID: <522762C5.9070500@oracle.com> Volker, build.sh was moved into make/ directory so you don't need special make/aix/build.sh Otherwise changes looks good. Let me sync jdk8 into ppc64/stage before we push new changes. Hotspot was updated in jdk8 already and it has 8014135 fix there. I am waiting jdk merge. Thanks, Vladimir On 9/4/13 8:33 AM, Volker Simonis wrote: > Hi all (sorry, the first mail was only sent to ppc-aix-port-dev), > > this webrev contains the necessary Makefiles for building the HotSpot on AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/8023034/ > > Most of the files are based on their corresponding Linux counterparts. > > Notice that although this RFR is flagged 'XL', the changes to shared > code are really tiny and only in make/defs.make where AIX is added to > the chain of not-Windows platforms. > > Of course the build itself will be possible only after the next change > ("8023038: PPC64 (part 15): Platform files for AIX/PPC64 support") > which will finally introduce the AIX platform source files. So not > much to test here - just read and enjoy:) > > Thank you and best regards, > Volker > From vladimir.kozlov at oracle.com Wed Sep 4 10:08:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 04 Sep 2013 10:08:37 -0700 Subject: RFR (XL): 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support In-Reply-To: References: Message-ID: <52276915.5020601@oracle.com> Looks fine to me. Thanks, Vladimir On 9/4/13 8:34 AM, Volker Simonis wrote: > Hi all (sorry, the first mail was only sent to ppc-aix-port-dev), > > this change finally contains the basic AIX platform source files: > > http://cr.openjdk.java.net/~simonis/webrevs/8023038 > > Together with the previous change ("8023034: PPC64 (part 14): > Implement AIX/PPC64 support in HotSpot makefiles") it enables the > build of an interpreter-only HotSpot VM on AIX. Assuming you have xlC > and the needed tools like GNU make in your path you can build it with > the following command line from within the hotspot/make directory: > > make ALT_BOOTDIR= ALT_OUTPUTDIR=/tmp/stage-opt-core/ > ARCH_DATA_MODEL=64 VERBOSE=true CC_INTERP=true OPENJDK=true > HOTSPOT_BUILD_JOBS=8 JVM_VARIANT_CORE=true all_productcore > > Notice that although this change is flagged 'XL' it only contains > platform dependent files in 'src/os/aix/', 'src/os_cpu/aix_ppc' and > 'src/share/vm/utilities/globalDefinitions_xlc.hpp' and doesn't affect > the current Oracle platforms at all. > > Thank you and best regards, > Volker > From erik.helin at oracle.com Wed Sep 4 10:36:35 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 4 Sep 2013 19:36:35 +0200 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts Message-ID: <20130904173635.GB3989@ehelin-thinkpad> Hi all, this patch changes the name of two flags: - -XX:+UseCompressedKlassPointers becomes -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') - -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize Background: These two flags were introduced when metaspace was merged into hs25. To use a smaller size for the Java object headers, the pointer in the object header that points to the Klass instance for the object can be 32 bits on a 64-bit system. Such pointers has been called compressed klass pointers. This is the same concept as compressed oops. For the current implementation of compressed class pointers to work, the Klass instances need to be placed in a continuous virtual memory space. This virtual memory space was called ClassMetaspace but this patch introduces the name CompressedClassSpace to emphasize that the concept is closely related to compressed klass pointers. The 'K' in the CompressedKlassPointers and CompressedClassSpace was changed to a 'C' since the C++ class Klass is an implementation detail that we do not want to expose to the users. I've also added a check in Arguments::parse that checks if the user has set CompressedClassSpaceSize when compressed class pointers are _not_ used. If this is the case, then the VM will print a warning. I've also added a test that verifies this actually happens. The change touches a lot of files, but the change in each file is very small. Webrev: http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 Testing: - JPRT - The jtreg tests in hotspot/test - Newly added jtreg test Thanks, Erik From harold.seigel at oracle.com Wed Sep 4 11:13:59 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 04 Sep 2013 14:13:59 -0400 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <20130904173635.GB3989@ehelin-thinkpad> References: <20130904173635.GB3989@ehelin-thinkpad> Message-ID: <52277867.8000508@oracle.com> Hi Erik, These changes look good. Just a small nit. In arguments.cpp, I think the new warning should say "has no affect" instead of "has no effect". Thanks, Harold On 9/4/2013 1:36 PM, Erik Helin wrote: > Hi all, > > this patch changes the name of two flags: > - -XX:+UseCompressedKlassPointers becomes > -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') > - -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize > > Background: > These two flags were introduced when metaspace was merged into hs25. > To use a smaller size for the Java object headers, the pointer in the > object header that points to the Klass instance for the object can be 32 > bits on a 64-bit system. Such pointers has been called compressed klass > pointers. This is the same concept as compressed oops. > > For the current implementation of compressed class pointers to work, the > Klass instances need to be placed in a continuous virtual memory space. > This virtual memory space was called ClassMetaspace but this patch > introduces the name CompressedClassSpace to emphasize that the concept > is closely related to compressed klass pointers. > > The 'K' in the CompressedKlassPointers and CompressedClassSpace was > changed to a 'C' since the C++ class Klass is an implementation detail > that we do not want to expose to the users. > > I've also added a check in Arguments::parse that checks if the user has > set CompressedClassSpaceSize when compressed class pointers > are _not_ used. If this is the case, then the VM will print a warning. I've > also added a test that verifies this actually happens. > > The change touches a lot of files, but the change in each file is very > small. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 > > Testing: > - JPRT > - The jtreg tests in hotspot/test > - Newly added jtreg test > > Thanks, > Erik From harold.seigel at oracle.com Wed Sep 4 11:26:21 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 04 Sep 2013 14:26:21 -0400 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <52277867.8000508@oracle.com> References: <20130904173635.GB3989@ehelin-thinkpad> <52277867.8000508@oracle.com> Message-ID: <52277B4D.2000303@oracle.com> Hi Erik, I looked into this a bit. You are correct in saying "has no effect". Sorry, Harold On 9/4/2013 2:13 PM, harold seigel wrote: > Hi Erik, > > These changes look good. Just a small nit. In arguments.cpp, I think > the new warning should say "has no affect" instead of "has no effect". > > Thanks, Harold > > On 9/4/2013 1:36 PM, Erik Helin wrote: >> Hi all, >> >> this patch changes the name of two flags: >> - -XX:+UseCompressedKlassPointers becomes >> -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') >> - -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize >> >> Background: >> These two flags were introduced when metaspace was merged into hs25. >> To use a smaller size for the Java object headers, the pointer in the >> object header that points to the Klass instance for the object can be 32 >> bits on a 64-bit system. Such pointers has been called compressed klass >> pointers. This is the same concept as compressed oops. >> >> For the current implementation of compressed class pointers to work, the >> Klass instances need to be placed in a continuous virtual memory space. >> This virtual memory space was called ClassMetaspace but this patch >> introduces the name CompressedClassSpace to emphasize that the concept >> is closely related to compressed klass pointers. >> >> The 'K' in the CompressedKlassPointers and CompressedClassSpace was >> changed to a 'C' since the C++ class Klass is an implementation detail >> that we do not want to expose to the users. >> >> I've also added a check in Arguments::parse that checks if the user has >> set CompressedClassSpaceSize when compressed class pointers >> are _not_ used. If this is the case, then the VM will print a >> warning. I've >> also added a test that verifies this actually happens. >> >> The change touches a lot of files, but the change in each file is very >> small. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 >> >> Testing: >> - JPRT >> - The jtreg tests in hotspot/test >> - Newly added jtreg test >> >> Thanks, >> Erik > From john.r.rose at oracle.com Wed Sep 4 12:01:59 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 4 Sep 2013 12:01:59 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <5213C0AA.5030706@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> <51F7F13E.8040104@oracle.com> <5213C0AA.5030706@oracle.com> Message-ID: Yes, please file this bug. I'm working on MH-related optimizations, and I am finding that preserving the required code pattern is blocking some optimizations, notably making customized variations of direct MHs. (The required code pattern is that the DMH in Local#0 has a member field which supplies the missing argument to the outgoing linker call. Making a variant DMH with a customized calling sequence is possible, but then it has wrong interactions with the MethodHandleInfo API. It would be easier to make a customized non-DMH, with no member field.) ? John On Aug 20, 2013, at 12:16 PM, serguei.spitsyn at oracle.com wrote: > John, > > Thank you for the comments! > In fact, I was very reluctant to implement it the way as it is in the webrev. > I'm in favor of the choice #3, and think, it is much better from the stability point of view. > Restoring the MemberName slot at deoptimization is not going to cause a performance degradation. > > If you and Christian are Ok with it I can file a new compiler bug to cover this issue. > > Thanks, > Serguei > > > On 8/12/13 3:30 PM, John Rose wrote: >> This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes. >> >> Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed. >> >> In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations. >> >> There are other approaches that might be more robust: >> 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument. >> 2. Do not make such frames visible to the user. >> 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization. >> >> ? John >> >> P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business! >> >> On Jul 30, 2013, at 10:00 AM, serguei.spitsyn at oracle.com wrote: >> >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ >>> >>> Thanks, >>> Serguei >>> >>> On 7/29/13 10:11 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> I'm fine with restoring to what was in the first webrev. >>>> >>>> Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile. >>>> >>>> Thanks, >>>> David >>>> >>>> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 7/29/13 8:22 PM, David Holmes wrote: >>>>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Christian and David, >>>>>>> >>>>>>> Thank you for the quick review and comments! >>>>>>> >>>>>>> This is a new version of webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>>>>> >>>>>> Sorry. You need that guard after all - at least you do if you continue >>>>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>>>>> will not exist: >>>>>> >>>>>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>>>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>>>>> >>>>> You are right, nice catch again. >>>>> Probably, it was the reason, I did not remove the #if/#endif in the >>>>> first place. :) >>>>> >>>>>> I'm a little surprised that the assembly code does not have that whole >>>>>> section guarded with INCLUDE_JVMTI - perhaps it should? >>>>> It should. >>>>> But it can be non-trivial because of other dependencies like the above. >>>>> To make it right, both _remove_activation_preserving_args_entry and >>>>> generate_earlyret_entry_for >>>>> must be isolated with #if INCLUDE_JVMTI. >>>>> Then more files have to be involved in this chain of changes: >>>>> interpreter/templateInterpreter.hpp >>>>> interpreter/templateInterpreter.hpp >>>>> memory/universe.hpp >>>>> memory/universe.cpp >>>>> code/codeCache.hpp >>>>> code/codeCache.cpp >>>>> . . . etc .. >>>>> >>>>> Please, note, that the HOTSWAP macro is used in many places as well. >>>>> I'm not sure we still need it, so that another decision is needed for it. >>>>> >>>>> So, it seems that this kind of clean up is going far beyond my fix. >>>>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >>>>> platform-dependent files as it was in the webrev v1. >>>>> I'm a little bit reluctant to open another clean-up bug for this issue >>>>> but maybe it is needed. >>>>> Please, let me know if you are comfortable with this solution. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Run this through a JPRT test build for productEmb to check that the >>>>>> minimal VM builds ok. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>>>>> >>>>>>>>> >>>>>>>> In the templateInterpreter code why did you put this guard on your new >>>>>>>> code (from x86_32 version): >>>>>>>> >>>>>>>> 1923 #if INCLUDE_JVMTI >>>>>>>> >>>>>>>> when the whole chunk of code this is situated in is specifically for >>>>>>>> JVMTI support >>>>>>>> >>>>>>>> 1824 // >>>>>>>> 1825 // JVMTI PopFrame support >>>>>>>> 1826 // >>>>>>>> >>>>>>>> ??? >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Summary: >>>>>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>>>>> >>>>>>>>> Description >>>>>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>>>>> site >>>>>>>>> that >>>>>>>>> takes an appendix and that call site is reexecuted the appendix is >>>>>>>>> not on >>>>>>>>> the stack anymore because it got removed by the adapter. >>>>>>>>> This fix is to detect such a case and push the appendix on the >>>>>>>>> stack >>>>>>>>> again before reexecution. >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>>>>> nsk.jdi.testlist >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei > From zhengyu.gu at oracle.com Wed Sep 4 13:23:55 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 04 Sep 2013 20:23:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 29 new changesets Message-ID: <20130904202530.7BF316256E@hg.openjdk.java.net> Changeset: 4a1efab850f4 Author: shade Date: 2013-08-26 17:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a1efab850f4 8023638: Add the regression test for 8006997 Summary: Add the relevant test and proofread the VM messages as well Reviewed-by: coleenp, mseledtsov, dcubed ! src/share/vm/runtime/arguments.cpp + test/runtime/contended/Options.java Changeset: a7d8baf4cca7 Author: dcubed Date: 2013-08-26 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a7d8baf4cca7 Merge Changeset: 91b93f523ec6 Author: acorn Date: 2013-08-26 11:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91b93f523ec6 8012294: remove generic handling for default methods Reviewed-by: kamg, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/globals.hpp Changeset: d80493ee6430 Author: acorn Date: 2013-08-27 01:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d80493ee6430 Merge - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/globals.hpp Changeset: 6b3ac96bada6 Author: jiangli Date: 2013-08-26 13:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b3ac96bada6 8023477: Invalid CP index when reading ConstantPool. Summary: Need to check for 0 case for InstanceKlass::_generic_signature_index. Reviewed-by: sspitsyn, sla ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java Changeset: b3596321fbf4 Author: jiangli Date: 2013-08-27 04:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b3596321fbf4 Merge Changeset: 7e7dd25666da Author: ccheung Date: 2013-08-26 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7e7dd25666da 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error Summary: removed offending EXCEPTION_MARK calls and code cleanup Reviewed-by: dholmes, iklam, coleenp, mseledtsov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp + test/runtime/LoadClass/LoadClassNegative.java + test/runtime/LoadClass/TestForName.java + test/runtime/LoadClass/dummy.jar Changeset: 5351fe805c12 Author: minqi Date: 2013-08-27 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5351fe805c12 Merge Changeset: f462e61bce87 Author: iklam Date: 2013-08-26 21:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f462e61bce87 8020622: create.bat on Windows failed to create project file for Visual Studio 2012 Summary: Treat VS2012 the same as VS2010. Reviewed-by: dcubed, kamg, minqi ! make/windows/create.bat ! make/windows/makefiles/rules.make Changeset: 35471dcba316 Author: iklam Date: 2013-08-27 03:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35471dcba316 Merge Changeset: c26d57fa08aa Author: iklam Date: 2013-08-27 16:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c26d57fa08aa Merge Changeset: 915cc4f3fb15 Author: acorn Date: 2013-08-28 08:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/915cc4f3fb15 8020489: VM crash when non-existent interface called by invokespecial Reviewed-by: kamg, coleenp ! src/share/vm/classfile/defaultMethods.cpp Changeset: cc56f122f3f7 Author: sla Date: 2013-08-29 11:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc56f122f3f7 8023720: (hotspot) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes, rbackman ! src/os/posix/vm/os_posix.cpp Changeset: 76482cbba706 Author: hseigel Date: 2013-08-29 10:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/76482cbba706 8016764: JVM does not prohibit invokespecial in c.f.v 51.0 that invokes default interface method in c.f.v 52.0 Summary: Check cfv before allowing invokespecial call to default method. Reviewed-by: kamg, acorn, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: dfc126b2f659 Author: hseigel Date: 2013-08-29 13:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dfc126b2f659 8022407: sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35 Summary: lower optimization level for unsafe.cpp due to MacOS Xcode 4.6.2 compiler optimization issue. Reviewed-by: coleenp, twisti, dholmes Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/gcc.make Changeset: d8e99408faad Author: dsamersoff Date: 2013-08-29 21:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8e99408faad 8009062: poor performance of JNI AttachCurrentThread after fix for 7017193 Summary: don't re-evaluate stack bounds for main thread before install guard page Reviewed-by: coleenp, dholmes, dlong ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + test/runtime/InitialThreadOverflow/DoOverflow.java + test/runtime/InitialThreadOverflow/invoke.cxx + test/runtime/InitialThreadOverflow/testme.sh Changeset: cef1e56a4d88 Author: dsamersoff Date: 2013-08-29 21:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cef1e56a4d88 Merge Changeset: 9758d9f36299 Author: coleenp Date: 2013-08-29 18:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9758d9f36299 8021954: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced Summary: declare all user-defined operator new()s within Hotspot code with the empty throw() exception specification Reviewed-by: coleenp, twisti, dholmes, hseigel, dcubed, kvn, ccheung Contributed-by: lois.foltan at oracle.com ! src/share/vm/adlc/arena.cpp ! src/share/vm/adlc/arena.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/park.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/utilities/array.hpp Changeset: c636758ea616 Author: dcubed Date: 2013-08-30 07:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c636758ea616 Merge ! src/os/posix/vm/os_posix.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 522d69638aa8 Author: zgu Date: 2013-08-30 11:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/522d69638aa8 6991327: using -Xprof trigger native memory leak Summary: Fixed a memory leak in FlatProfiler::record_thread_tick() method Reviewed-by: dholmes, ccheung ! src/share/vm/runtime/fprofiler.cpp Changeset: 491de79915eb Author: zgu Date: 2013-08-30 12:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/491de79915eb Merge ! src/share/vm/runtime/fprofiler.cpp Changeset: ac2764460da7 Author: zgu Date: 2013-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ac2764460da7 Merge Changeset: ca0501b58953 Author: hseigel Date: 2013-08-30 15:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca0501b58953 8024050: Incorrect optimization level and comment specified for unsafe.cpp Summary: Fix comments and optimization level. Reviewed-by: rdurbin, coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/gcc.make Changeset: d8ff06fb87ae Author: hseigel Date: 2013-08-30 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8ff06fb87ae Merge Changeset: abff50660360 Author: hseigel Date: 2013-08-30 15:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/abff50660360 Merge Changeset: 3a1df0dce3e5 Author: acorn Date: 2013-08-30 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a1df0dce3e5 8023872: Verification error in generated lambda classes Summary: skip verification for generated lambda classes Reviewed-by: kamg, dholmes ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: 735f94656acc Author: acorn Date: 2013-08-30 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/735f94656acc Merge Changeset: 2918c7e21a3a Author: acorn Date: 2013-08-30 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2918c7e21a3a Merge Changeset: 35b99e7e0af2 Author: hseigel Date: 2013-09-01 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35b99e7e0af2 8023381: VM fails to initialize in runtime/CDSCompressedKPtrs/XShareAuto.java runtime/SharedArchiveFile/CdsSameObjectAlignment.java Summary: Improve handling when CDS archive cannot be mapped Reviewed-by: kvn, dholmes, mseledtsov ! src/share/vm/memory/filemap.cpp ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java From volker.simonis at gmail.com Wed Sep 4 14:49:08 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Sep 2013 23:49:08 +0200 Subject: RFR (XL): 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles In-Reply-To: <522762C5.9070500@oracle.com> References: <522762C5.9070500@oracle.com> Message-ID: On Wednesday, September 4, 2013, Vladimir Kozlov wrote: > Volker, > > build.sh was moved into make/ directory so you don't need special > make/aix/build.sh > > Thanks for the hint. You're absolutely right. The file still contained references to JDK1.2_fcs as default setting for JAVA_HOME so I suppose it was hardly ever used during the build on AIX:) Otherwise changes looks good. > > Let me sync jdk8 into ppc64/stage before we push new changes. Hotspot was > updated in jdk8 already and it has 8014135 fix there. I am waiting jdk > merge. That's fine for me. I already saw today that 8014135 is coming. After the sync do you still want to push it (and part 15) yourself through JPRT or can I push it directly because it doesn't touch any shared code? Thanks, Volker > Thanks, > Vladimir > > On 9/4/13 8:33 AM, Volker Simonis wrote: > >> Hi all (sorry, the first mail was only sent to ppc-aix-port-dev), >> >> this webrev contains the necessary Makefiles for building the HotSpot on >> AIX: >> >> http://cr.openjdk.java.net/~**simonis/webrevs/8023034/ >> >> Most of the files are based on their corresponding Linux counterparts. >> >> Notice that although this RFR is flagged 'XL', the changes to shared >> code are really tiny and only in make/defs.make where AIX is added to >> the chain of not-Windows platforms. >> >> Of course the build itself will be possible only after the next change >> ("8023038: PPC64 (part 15): Platform files for AIX/PPC64 support") >> which will finally introduce the AIX platform source files. So not >> much to test here - just read and enjoy:) >> >> Thank you and best regards, >> Volker >> >> From vladimir.kozlov at oracle.com Wed Sep 4 15:34:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 04 Sep 2013 15:34:11 -0700 Subject: RFR (XL): 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles In-Reply-To: References: <522762C5.9070500@oracle.com> Message-ID: <5227B563.6050707@oracle.com> On 9/4/13 2:49 PM, Volker Simonis wrote: > On Wednesday, September 4, 2013, Vladimir Kozlov wrote: > >> Volker, >> >> build.sh was moved into make/ directory so you don't need special >> make/aix/build.sh >> >> > Thanks for the hint. You're absolutely right. The file still contained > references to JDK1.2_fcs as default setting for JAVA_HOME so I suppose it > was hardly ever used during the build on AIX:) > > Otherwise changes looks good. >> >> Let me sync jdk8 into ppc64/stage before we push new changes. Hotspot was >> updated in jdk8 already and it has 8014135 fix there. I am waiting jdk >> merge. > > > That's fine for me. I already saw today that 8014135 is coming. > > After the sync do you still want to push it (and part 15) yourself through > JPRT or can I push it directly because it doesn't touch any shared code? You can push it directly. I will do sync tomorrow. Thanks, Vladimir > > Thanks, > Volker > > >> Thanks, >> Vladimir >> >> On 9/4/13 8:33 AM, Volker Simonis wrote: >> >>> Hi all (sorry, the first mail was only sent to ppc-aix-port-dev), >>> >>> this webrev contains the necessary Makefiles for building the HotSpot on >>> AIX: >>> >>> http://cr.openjdk.java.net/~**simonis/webrevs/8023034/ >>> >>> Most of the files are based on their corresponding Linux counterparts. >>> >>> Notice that although this RFR is flagged 'XL', the changes to shared >>> code are really tiny and only in make/defs.make where AIX is added to >>> the chain of not-Windows platforms. >>> >>> Of course the build itself will be possible only after the next change >>> ("8023038: PPC64 (part 15): Platform files for AIX/PPC64 support") >>> which will finally introduce the AIX platform source files. So not >>> much to test here - just read and enjoy:) >>> >>> Thank you and best regards, >>> Volker >>> >>> From josev3lopez at yahoo.com Wed Sep 4 20:34:55 2013 From: josev3lopez at yahoo.com (Jose) Date: Wed, 4 Sep 2013 20:34:55 -0700 Subject: No subject Message-ID: <62833CF9-E8D3-4393-8926-3A684D2CCB71@yahoo.com> Hi Sent from my iPhone From erik.helin at oracle.com Thu Sep 5 01:51:49 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 5 Sep 2013 10:51:49 +0200 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <52277B4D.2000303@oracle.com> References: <20130904173635.GB3989@ehelin-thinkpad> <52277867.8000508@oracle.com> <52277B4D.2000303@oracle.com> Message-ID: <20130905085149.GA2080@ehelin-thinkpad> Hi Harold, thanks for reviewing! Erik On 2013-09-04, harold seigel wrote: > Hi Erik, > > I looked into this a bit. You are correct in saying "has no effect". > > Sorry, Harold > > On 9/4/2013 2:13 PM, harold seigel wrote: > >Hi Erik, > > > >These changes look good. Just a small nit. In arguments.cpp, I > >think the new warning should say "has no affect" instead of "has > >no effect". > > > >Thanks, Harold > > > >On 9/4/2013 1:36 PM, Erik Helin wrote: > >>Hi all, > >> > >>this patch changes the name of two flags: > >>- -XX:+UseCompressedKlassPointers becomes > >> -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') > >>- -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize > >> > >>Background: > >>These two flags were introduced when metaspace was merged into hs25. > >>To use a smaller size for the Java object headers, the pointer in the > >>object header that points to the Klass instance for the object can be 32 > >>bits on a 64-bit system. Such pointers has been called compressed klass > >>pointers. This is the same concept as compressed oops. > >> > >>For the current implementation of compressed class pointers to work, the > >>Klass instances need to be placed in a continuous virtual memory space. > >>This virtual memory space was called ClassMetaspace but this patch > >>introduces the name CompressedClassSpace to emphasize that the concept > >>is closely related to compressed klass pointers. > >> > >>The 'K' in the CompressedKlassPointers and CompressedClassSpace was > >>changed to a 'C' since the C++ class Klass is an implementation detail > >>that we do not want to expose to the users. > >> > >>I've also added a check in Arguments::parse that checks if the user has > >>set CompressedClassSpaceSize when compressed class pointers > >>are _not_ used. If this is the case, then the VM will print a > >>warning. I've > >>also added a test that verifies this actually happens. > >> > >>The change touches a lot of files, but the change in each file is very > >>small. > >> > >>Webrev: > >>http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ > >> > >>Bug: > >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 > >> > >>Testing: > >>- JPRT > >>- The jtreg tests in hotspot/test > >>- Newly added jtreg test > >> > >>Thanks, > >>Erik > > > From niclas.adlertz at oracle.com Thu Sep 5 04:12:08 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Thu, 05 Sep 2013 11:12:08 +0000 Subject: hg: hsx/hotspot-main/hotspot: 18 new changesets Message-ID: <20130905111243.BA5B262599@hg.openjdk.java.net> Changeset: 766fac3395d6 Author: kvn Date: 2013-08-23 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/766fac3395d6 8012972: Incremental Inlining should support scalar replaced object in debug info Summary: store in _first_index not absolute index but an index relative to the last (youngest) jvms->_scloff value Reviewed-by: roland, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: b17d8f6d9ed7 Author: kvn Date: 2013-08-23 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b17d8f6d9ed7 8023472: C2 optimization breaks with G1 Summary: set control edge for previous value load in G1 pre-barrier Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp + test/compiler/gcbarriers/G1CrashTest.java Changeset: f98f5d48f511 Author: roland Date: 2013-08-21 13:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f98f5d48f511 7199175: JSR 292: C1 needs patching when invokedynamic/invokehandle call site is not linked Summary: Do patching rather bailing out for unlinked call with appendix Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: e1fbb86b47e4 Author: roland Date: 2013-08-26 16:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e1fbb86b47e4 8016277: Crash in nmethod::is_compiled_by_c1() on x86 Summary: Method pointer for zombie methods may be invalid Reviewed-by: kvn, coleenp ! src/share/vm/code/nmethod.cpp Changeset: e47de6dfec5d Author: vlivanov Date: 2013-08-26 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e47de6dfec5d 8022456: LogCompilation tool does not work with C1 output again Reviewed-by: kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: 74608df95ba3 Author: vlivanov Date: 2013-08-26 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/74608df95ba3 8022595: JSR292: deadlock during class loading of MethodHandles, MethodHandleImpl & MethodHandleNatives Reviewed-by: kvn, coleenp, dholmes ! src/share/vm/runtime/thread.cpp + test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 022415fe638e Author: vlivanov Date: 2013-08-26 21:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/022415fe638e Merge Changeset: 59982ff9e0ec Author: rbackman Date: 2013-08-20 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59982ff9e0ec 8022283: Assertion failed: assert(is_loaded() && field->holder()->is_loaded() && klass()->is_subclass_of (field->holder())) failed: invalid access Reviewed-by: roland, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstance.cpp Changeset: 58e010ab2d06 Author: rbackman Date: 2013-08-27 19:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/58e010ab2d06 Merge Changeset: 650868c062a9 Author: adlertz Date: 2013-08-26 12:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/650868c062a9 8023691: Create interface for nodes in class Block Summary: Create public methods for accessing the nodes in a block Reviewed-by: kvn, roland ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp Changeset: 7181dd13a6c4 Author: adlertz Date: 2013-08-27 21:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7181dd13a6c4 Merge Changeset: 29aa8936f03c Author: kvn Date: 2013-08-28 11:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/29aa8936f03c 8023597: Optimize G1 barriers code for unsafe load_store Summary: Avoid loading old values in G1 pre-barriers for inlined unsafe load_store nodes. Reviewed-by: kvn, tonyp Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp Changeset: 8947af8a9cec Author: vlivanov Date: 2013-08-29 22:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8947af8a9cec 8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check Reviewed-by: kvn, twisti ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4b078f877b56 Author: adlertz Date: 2013-09-01 19:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4b078f877b56 8023988: Move local scheduling of nodes to the CFG creation and code motion phase (PhaseCFG) Summary: Moved local scheduling code from class Block to class PhaseCFG Reviewed-by: kvn, roland ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 40ed2dc92a79 Author: adlertz Date: 2013-09-01 19:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/40ed2dc92a79 Merge Changeset: 27ffd1c4537b Author: rbackman Date: 2013-09-02 13:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/27ffd1c4537b Merge ! src/share/vm/runtime/thread.cpp Changeset: a9a968364704 Author: adlertz Date: 2013-09-02 22:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a9a968364704 8024095: Missing brackets in local scheduling code. Summary: Added brackets for if-statement Reviewed-by: kvn, roland ! src/share/vm/opto/lcm.cpp Changeset: 3bfb204913de Author: adlertz Date: 2013-09-05 10:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3bfb204913de Merge ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/node.hpp From volker.simonis at gmail.com Thu Sep 5 05:20:57 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 5 Sep 2013 14:20:57 +0200 Subject: new convention for hsx project repository names In-Reply-To: <21025.7541.995077.658147@oracle.com> References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> <21025.7541.995077.658147@oracle.com> Message-ID: Hi John, HotSpot versioning has always been a kind of mystery. I'll try to explain my understanding of if before I'll come to my question: hsx/hsx23.1 |-----------------------> | ^ | | hsx/hsx23 |------------------------> | ^ ^ ^ | | | | | | + + + hsx/hotspot-main |------hs23-----|------hs24-------|------hs25----> The easy part is the "hsx/hotspot-main" repository. It contains the linear, incremental development code line of the HotSpot. For convenience, larger development frames are consecutively numbered with HotSpot version numbers (i.e. hs23, hs24, etc.). Once a major development period is over (and before the next one begins) the HotSpot may be branched into a stabilization repository which until now is named according to the corresponding HotSpot version number (i.e. hs23 -> hsx23). As the name "stabilization repositories" implies, they are used to stabilize a HotSpot version for a release. Therefore changes from the main development code line are selectively integrated into the hsxXY repositories (indicated by the '+' sign in my drawing) as needed. Actually, the general rule of thumb is that all the changes have to go trough the development code line (i.e. "hsx/hotspot-main") before they can be integrated into a "hsxXY" repository although it already happened in the past that this rule has been violated. At some point in time, hsxXY is considered stable and will be shipped inside a Java release - say jdk7uMN. But things get more complicated: at a certain point in time, there may be a need to stabilize multiple hsxXY versions for different releases in parallel (e.g. the next feature and the next security release or the next security release and an exceptional security release). In such a case, new hsx repositories are created with an additional, minor version number (e.g. hsx23.1, hsx23.2). At this point things already get nebulous, because the relation of two hsx versions hsx.XY.A and hsxXY.B is not always clear to me - i.e. it is not always easy to see from which common ancestor change set they are branched. Another problem is that within the OpenJDK we usually don't see all the different hsx.XY.A repositories (some like the ones for security fixes are Oracle-internal). Instead, they are all merged into the common hsx.XY repository after they have been released. So far that's how I understand the current situation (comments and corrections always welcome:). Now my questions: 1. Will you still maintain the major and minor HotSpot versions numbers in make/hotspot_version after branching the HotSpot sources to hsx/jdkXu and hsx/jdkXuYZ 2. What happens if hs26 will go into jdk8uXY. From my understanding of your proposal we will end up with hs26 being in hsx/jdk9 AND hsx/jdk8u AND hsx/jdk8uXY AND any other hsx/jdk8uNM with NM > XY. Morover hsx/jdk8u will switch from hsx25 to hsx26. 3. What happens with the repositories which are not publicly visible? Will they all be merged into hsx/jdk8u? We then may get the strange situation that we merged hs26 into hsx/jdk8u because it will be backported into jdk8. Later on, but before a jdk8 with hs26 will be released, we merge hs25.N (from a security release) into hsx/jdk8u. This seems much more confusing than having distinct hsx/hs25.N and hsx/hs26.M repositories. 4. Why not just stay with the current scheme and just provide a list with the hs to jdkXu mapping at a prominent place? In my opinion, your scheme will probably always cause trouble because there is no one-to-one relation between the HotSpot and JDK version. It would be hard to guarantee this because there might be always good reasons to downport a newer HotSpot version into an already released JDK. Thank you and best regards, Volker On Sat, Aug 31, 2013 at 12:32 AM, John Coomes wrote: > David Holmes (david.holmes at oracle.com) wrote: > > Hi John, > > > > Can you clarify how the repository name change will affect the actual > > hotspot version info that is maintained in the repo, and reported via > > -version and -Xinternalversion. > > Hi David, > > The new convention only affects the repository names; the version > reported by the JVM will remain the same for now. > > Changing the version string is an obvious future step, but since it's > visible to users (not just developers), we have to be a bit more > careful. Look for more email on that in the coming weeks. > > -John > > > On 30/08/2013 2:09 PM, John Coomes wrote: > > > The hsx Project has maintained a version number for HotSpot that is > > > distinct from the JDK version--for example HotSpot version hs24 is > > > being delivered into jdk7u40, and hs25 into jdk8. (For interested > > > readers, some background info about separate versions is included at > > > the end of this message.) > > > > > > The separate version has also been reflected in repository paths, e.g.: > > > > > > http://hg.openjdk.java.net/hsx/hsx24 > > > http://hg.openjdk.java.net/hsx/hsx23 > > > http://hg.openjdk.java.net/hsx/hsx23.2 > > > http://hg.openjdk.java.net/hsx/hsx23.4 > > > ... > > > > > > One often-mentioned problem with this naming scheme is that the > > > correspondence between an hsx repository and the JDK release into which > > > it will be delivered is not obvious. So we are planning on changing > the > > > repository naming convention going forward. > > > > > > More precisely, the new repository for HotSpot (and HotSpot-related) > > > changes targeting jdk7u60 and later 7 updates would be: > > > > > > http://hg.openjdk.java.net/hsx/jdk7u > > > > > > (The old convention would have used the name http://.../hsx/hsx24.) > > > This new repo will correspond to the jdk7u on-going development repo, > > > i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. > > > > > > Extending this a little into the future, once jdk7u60 reaches a point > > > where a separate stabilization repo is needed, we will create > > > http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u > > > repo would change to target the following jdk7u update release (if > > > there is one). > > > > > > Similar conventions would apply to repositories for jdk8 updates once > > > we have a need for them. > > > > > > Existing hsx repos should continue to be used; in particular, we will > > > continue to use the on-going development repos for the forseeable > > > future: > > > > > > http://hg.openjdk.java.net/hsx/hotspot-main > > > http://hg.openjdk.java.net/hsx/hotspot-comp > > > http://hg.openjdk.java.net/hsx/hotspot-emb > > > http://hg.openjdk.java.net/hsx/hotspot-gc > > > http://hg.openjdk.java.net/hsx/hotspot-rt > > > > > > These are currently targeting jdk8, and will switch to jdk9 in the near > > > future. At that point a new jdk8 stabilization repo would be created: > > > > > > http://hg.openjdk.java.net/hsx/jdk8 > > > > > > to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is > > > currently used only by the hotspot gatekeeper, Alejandro Murillo). > > > > > > Despite the length of this message, I think the naming change is > > > straightforward and will (slightly) simplify HotSpot development. > > > Since there are already HotSpot changes pending for jdk7u60, I want to > > > create the new repo within the next few days. If you have questions > > > or feedback, please follow-up on the list. > > > > > > Background on the separate HotSpot version number: > > > > > > Because the same HotSpot source has been delivered simultaneously into > > > multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 > and > > > into jdk7u4, builds of hs22 were delivered into early jdk8 builds and > > > into jdk7u2, and so on), a separate HotSpot version facilitated > tracking > > > the sources as they propagated to different releases. But at the same > > > time, it also imposed the overhead of having to map from a HotSpot > > > version to a JDK version and back again. This is not always simple, > > > particularly for those that do not work with HotSpot on a day-to-day > > > basis. > > > > > > More recent hsx versions (hs24 and hs25), have really targeted only a > > > single JDK release (although a few builds of hs24 did go into both jdk8 > > > and into jdk7u). We expect this trend to continue, and thus the > > > overhead of mapping from a HotSpot version to a JDK version is > > > unnecessary. > > > > > > -John > > > > From thomas.schatzl at oracle.com Thu Sep 5 07:14:54 2013 From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com) Date: Thu, 05 Sep 2013 14:14:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130905141512.537D5625A0@hg.openjdk.java.net> Changeset: 88c255656030 Author: mgerdin Date: 2013-08-22 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/88c255656030 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld Summary: When using NUMA and large pages we need to ease the requirement on which node the memory should be allocated on. To avoid the SIGBUS we now use the memory policy MPOL_PREFERRED, which prefers a certain node, instead of MPOL_BIND, which requires a certain node. Reviewed-by: jmasa, pliden Contributed-by: stefan.johansson at oracle.com ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 0d59407e7e09 Author: jmasa Date: 2013-08-29 06:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0d59407e7e09 Merge ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 84683e78e713 Author: brutisso Date: 2013-08-30 07:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/84683e78e713 8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size Reviewed-by: tonyp, tschatzl, sjohanss ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: f175e3678be2 Author: ehelin Date: 2013-08-22 11:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f175e3678be2 8020692: TestGCEventMixed.java failed because of timestamp in event after end event Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp Changeset: a701c16e8bbf Author: jmasa Date: 2013-09-04 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a701c16e8bbf 8013938: Native OOME on fastdebug VM on Solaris Reviewed-by: azeemj, brutisso, kvn, tschatzl ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 428025878417 Author: jmasa Date: 2013-09-04 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/428025878417 Merge Changeset: bb57d48691f5 Author: tschatzl Date: 2013-09-05 14:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bb57d48691f5 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp From mikael.gerdin at oracle.com Thu Sep 5 09:08:26 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 05 Sep 2013 18:08:26 +0200 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <20130904173635.GB3989@ehelin-thinkpad> References: <20130904173635.GB3989@ehelin-thinkpad> Message-ID: <5228AC7A.8030707@oracle.com> Erik, On 2013-09-04 19:36, Erik Helin wrote: > Hi all, > > this patch changes the name of two flags: > - -XX:+UseCompressedKlassPointers becomes > -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') > - -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize > > Background: > These two flags were introduced when metaspace was merged into hs25. > To use a smaller size for the Java object headers, the pointer in the > object header that points to the Klass instance for the object can be 32 > bits on a 64-bit system. Such pointers has been called compressed klass > pointers. This is the same concept as compressed oops. > > For the current implementation of compressed class pointers to work, the > Klass instances need to be placed in a continuous virtual memory space. > This virtual memory space was called ClassMetaspace but this patch > introduces the name CompressedClassSpace to emphasize that the concept > is closely related to compressed klass pointers. > > The 'K' in the CompressedKlassPointers and CompressedClassSpace was > changed to a 'C' since the C++ class Klass is an implementation detail > that we do not want to expose to the users. > > I've also added a check in Arguments::parse that checks if the user has > set CompressedClassSpaceSize when compressed class pointers > are _not_ used. If this is the case, then the VM will print a warning. I've > also added a test that verifies this actually happens. > > The change touches a lot of files, but the change in each file is very > small. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ Thanks for taking care of this. Change looks good to me. /Mikael > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 > > Testing: > - JPRT > - The jtreg tests in hotspot/test > - Newly added jtreg test > > Thanks, > Erik > From john.coomes at oracle.com Thu Sep 5 10:32:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:32:00 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b106 for changeset d3be8e3b429d Message-ID: <20130905173211.E7773625B3@hg.openjdk.java.net> Changeset: d6a32e3831aa Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d6a32e3831aa Added tag jdk8-b106 for changeset d3be8e3b429d ! .hgtags From john.coomes at oracle.com Thu Sep 5 10:31:40 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:31:40 +0000 Subject: hg: hsx/hotspot-main: 6 new changesets Message-ID: <20130905173141.4079E625B0@hg.openjdk.java.net> Changeset: 21198f51bc7e Author: erikj Date: 2013-08-29 15:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/21198f51bc7e 8003162: build-infra: Improve suggestions for missing packages on linux Reviewed-by: tbell, omajid ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 Changeset: 92facce22941 Author: erikj Date: 2013-08-30 10:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/92facce22941 8023957: Lock down version of autoconf Reviewed-by: chegar, dsamersoff, tbell, dholmes ! README-builds.html ! common/autoconf/autogen.sh ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh Changeset: 2aacc7080d36 Author: katleman Date: 2013-09-03 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2aacc7080d36 Merge Changeset: 0f6dde6231bd Author: ihse Date: 2013-09-04 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0f6dde6231bd 8024155: Fix 'make CONF= ' Reviewed-by: erikj, tbell ! NewMakefile.gmk ! common/makefiles/Main.gmk Changeset: 8e7b4d9fb00f Author: erikj Date: 2013-09-04 10:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8e7b4d9fb00f Merge ! NewMakefile.gmk ! common/makefiles/Main.gmk Changeset: 58f1b6f32b47 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/58f1b6f32b47 Added tag jdk8-b106 for changeset 8e7b4d9fb00f ! .hgtags From john.coomes at oracle.com Thu Sep 5 10:32:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:32:21 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b106 for changeset 6908370afe83 Message-ID: <20130905173228.CA7A8625B4@hg.openjdk.java.net> Changeset: e3c9328f7563 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/e3c9328f7563 Added tag jdk8-b106 for changeset 6908370afe83 ! .hgtags From john.coomes at oracle.com Thu Sep 5 10:32:43 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:32:43 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b106 for changeset c817276bd870 Message-ID: <20130905173417.2F4DD625B5@hg.openjdk.java.net> Changeset: aafc0f332658 Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aafc0f332658 Added tag jdk8-b106 for changeset c817276bd870 ! .hgtags From john.coomes at oracle.com Thu Sep 5 10:36:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:36:09 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b106 for changeset fcd768844b99 Message-ID: <20130905173626.DB797625B6@hg.openjdk.java.net> Changeset: 3f274927ec18 Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3f274927ec18 Added tag jdk8-b106 for changeset fcd768844b99 ! .hgtags From john.coomes at oracle.com Thu Sep 5 10:36:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:36:37 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b106 for changeset bf70cbd2c836 Message-ID: <20130905173643.1BDBD625B7@hg.openjdk.java.net> Changeset: f35e1255024b Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f35e1255024b Added tag jdk8-b106 for changeset bf70cbd2c836 ! .hgtags From john.coomes at oracle.com Thu Sep 5 10:31:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 05 Sep 2013 17:31:49 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b106 for changeset 2e3a056c84a7 Message-ID: <20130905173153.A1B70625B1@hg.openjdk.java.net> Changeset: 23fc34133152 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/23fc34133152 Added tag jdk8-b106 for changeset 2e3a056c84a7 ! .hgtags From dawid.weiss at gmail.com Thu Sep 5 13:09:29 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 5 Sep 2013 22:09:29 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> <521BFBD4.7090800@oracle.com> Message-ID: My quest continues :) I thought it'd be interesting to see how far back I can trace this issue. I fetched the official binaries for jdk17 (windows, 32-bit) and did a binary search with the failing Lucene test command. The results show that, in short: ... jdk1.7.0_03: PASSES jdk1.7.0_04: FAILS ... and are consistent before and after. jdk1.7.0_04, 64-bit does *NOT* exhibit the issue (and neither does any version afterwards, it only happens on 32-bit; perhaps it's because of smaller number of available registers and the need to spill?). jdk1.7.0_04 was when G1GC was "officially" made supported but I don't think this plays a big difference. I'll see if I can bsearch on mercurial revisions to see which particular revision introduced the problem. Anyway, the problem has to be a long-standing issue and not a regression. Which makes it even more interesting I guess. Dawid On Mon, Sep 2, 2013 at 11:31 AM, Dawid Weiss wrote: > Oh, I forgot to mention - that incremented value cannot be saved to > [esp + #136] immediately because there's a value read based on the > unincremented value (buffer[upto++]). This is all fine, but the > problem is that the incremented spill slot [esp + #144] is never > copied to that other spill slot that is read from the other inline. > > Again -- I have no clue what makes this particular code path so > special but I can see it in the debugger clearly. > > Dawid > > On Mon, Sep 2, 2013 at 11:17 AM, Dawid Weiss wrote: >> I've traced the assembly on a running instance. The problem is quite >> interesting -- the code in question is purely computational, I still >> don't see how G1GC can be of importance here. In short what's >> happening is a method gets inlined in a larger loop more than once and >> a field access is placed on the esp spill. The problem is both of >> these inlines use a different spill slot and one of the updates is not >> properly propagated -- it is saved to one spill slot, then the code >> execution flow returns to the top of the loop and another inline reads >> a stale value from another spill slot. When you disable escape >> analysis everything works as expected. >> >> The crucial block is: >> >> 7e25 B1020: # B405 B1021 <- B1017 B1019 Freq: 0.00811184 // XXX >> jump from b1017 >> 7e25 MOV EBX,[ESP + #136] // ebx = 80e >> 7e2c MOV ECX,EBX >> 7e2e INC ECX // ecx = 80f, increment. >> 7e2f MOV [ESP + #144],ECX // this is the >> incremented spill but it never gets propagated to [esp + #136] or >> re-read from memory. >> 7e36 MOV EBX,[ESP + #132] >> 7e3d MOV [EBX + #12],ECX ! Field: >> org/apache/lucene/index/ByteSliceReader.upto >> 7e40 MOV EBX,[ESP + #152] >> 7e47 TEST EBX,EBX >> 7e49 Jne B405 P=0.999999 C=-1.000000 // taken, null check >> >> >> The incremented local value of upto gets saved to [ESP + #144] and to >> memory but upon reiterating the loop it is re-read from [ESP + #136] >> so it looks like a dependency is missed somewhere in the graph causing >> escape analysis to fail. >> >> Ehm, obviously I have no idea how or where to fix this in the JVM code :) >> >> Full optoassembly dump and annotated opto assembly analysis is here: >> http://www.cs.put.poznan.pl/dweiss/tmp/hotspot-bug-analysis.zip >> >> Let me know if I can do anything else. >> >> Dawid >> >> On Tue, Aug 27, 2013 at 9:15 AM, Dawid Weiss wrote: >>> Thanks Vladimir. I had the impression I may be looking at the >>> interpreter. Just for completeness, I also thought/tried the following >>> ways to stop at the jitted code: >>> >>> 1) call Windows debugger API endpoints from kernel32 -- >>> >>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx >>> >>> via JNI/ JNA. This worked surprisingly well -- you can even wait for >>> the debugger to attached to the code in a loop, works like a charm. :) >>> Although once you break into the debugger I again couldn't make sense >>> of the stack -- probably the infrequent call causes a deopt again and >>> we're back in the interpreter. >>> >>> 2) use Unsafe to force a null pointer dereference :) This should send >>> a debugger signal, right? I didn't try it though, didn't have the time >>> yet. I suspect it may be moved to an infrequent trap too and we're >>> back where we started, eh. >>> >>>> I still did not have time to look on your logs. >>> >>> No worries, it's been a very very educational experience for me. >>> Besides, I used to write tons of assembly (not on x86) and it actually >>> feels very good to be back at the assembly mnemonic level ;) >>> >>> Don't spoil my weekend pet project :) And seriously -- if you want to >>> check out those logs let me know in advance and I'll prepare an update >>> with hsx-tip if needed. >>> >>> Dawid >>> >>> On Tue, Aug 27, 2013 at 3:07 AM, Vladimir Kozlov >>> wrote: >>>> Dawid, >>>> >>>> Let it crush with AbortVMOnException (without ShowMessageBoxOnError) and >>>> look on call stack in hs_err_pidxxx.log file. Jited code usually have >>>> uncommon trap for exceptions so the method most likely was deoptimized and >>>> you will see interpeter frames on call stack instead of compiled/jited. >>>> There should be deoptimization event listed down in hs_err_pidxxx.log which >>>> may say in which address in jited code it hit uncommon trap. You can look on >>>> it in optoassembly output. Then during method compilation >>>> (-XX:+PrintCompilation -Xbatch -XX:CICompilerCount=1 should give you info >>>> when the method is compiled, you can verify it in Compile() by >>>> this->method()->print()) in debugger stop in ciEnv::register_method() after >>>> call to nmethod::new_nmethod(). nm->insts_begin() shows where instructions >>>> start. Add instruction offset from optoassembly and set breakepoint at that >>>> address. This way you can stop in jited code. >>>> >>>> G1 affects inlining since its write barriers code size is larger then other >>>> collectors (it has pre and post barriers for oop stores). >>>> >>>> I still did not have time to look on your logs. >>>> >>>> Vladimir >>>> >>>> >>>> On 8/26/13 12:56 PM, Dawid Weiss wrote: >>>>>> >>>>>> An ideal scenario and what I want to achieve is I'd like to stop on an >>>>>> assertion somewhere in the jitted code and go back to it to follow the >>>>>> execution (so that I can see what code is responsible for the issing >>>>> >>>>> increment). I'll need to sync this up (manually or otherwise) with the >>>>> optoassembly too [...] >>>>> >>>>> Would somebody be so kind and provide some light on whether the above >>>>> is feasible? I'm getting up to speed with visual studio -- haven't >>>>> used assembly-level debugging in a longer while -- but I'm having >>>>> troubles connecting the dots with verbose optoassembly output (the >>>>> addresses don't seem to match). Thanks and again, apologies if it's >>>>> something trivial but I couldn't find any helpful resources on the >>>>> net. >>>>> >>>>> Dawid >>>>> >>>>> On Sun, Aug 25, 2013 at 9:43 PM, Dawid Weiss >>>>> wrote: >>>>>> >>>>>> I know why the assertion is hit. I still don't know (and probably >>>>>> won't figure it out) why it is so difficult to reproduce or which >>>>>> optimization leads to it. >>>>>> >>>>>> In short, the following code in ByteSliceReader#readByte: >>>>>> >>>>>> public byte readByte() { >>>>>> assert !eof(); >>>>>> assert upto <= limit; >>>>>> if (upto == limit) { >>>>>> nextSlice(); >>>>>> } >>>>>> return buffer[upto++]; >>>>>> } >>>>>> >>>>>> is inlined in a number of places. If I include: >>>>>> >>>>>> public byte readByte() { >>>>>> assert !eof(); >>>>>> assert upto <= limit; >>>>>> if (upto == limit) { >>>>>> nextSlice(); >>>>>> baz = upto; >>>>>> } >>>>>> return buffer[upto++]; >>>>>> } >>>>>> static int baz; >>>>>> >>>>>> I see a number of assignments to 'baz'. This is because methods like >>>>>> readVInt fork out many conditional branches, as in: >>>>>> >>>>>> public int readVInt() throws IOException { >>>>>> byte b = readByte(); >>>>>> if (b >= 0) return b; >>>>>> int i = b & 0x7F; >>>>>> b = readByte(); >>>>>> i |= (b & 0x7F) << 7; >>>>>> if (b >= 0) return i; >>>>>> b = readByte(); >>>>>> i |= (b & 0x7F) << 14; >>>>>> if (b >= 0) return i; >>>>>> b = readByte(); >>>>>> i |= (b & 0x7F) << 21; >>>>>> if (b >= 0) return i; >>>>>> b = readByte(); >>>>>> // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste >>>>>> errors: >>>>>> i |= (b & 0x0F) << 28; >>>>>> if ((b & 0xF0) == 0) return i; >>>>>> throw new IOException("Invalid vInt detected (too many bits)"); >>>>>> } >>>>>> >>>>>> One of these executions (when upto == limit, and possibly with some >>>>>> other upper condition) leads to missing increment on buffer[upto++] -- >>>>>> upto remains unmodified (but the value at buffer[upto] is returned >>>>>> properly). Because upto is moved to a register in many of those >>>>>> inlined methods I suspect either the register may be incremented and >>>>>> not saved or the increment may be removed due to some local escape >>>>>> analysis magic (that has to be incorrect, obviously). How G1GC >>>>>> interacts with all this (remember, it only happens with G1GC) I have >>>>>> no clue. >>>>>> >>>>>> Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't >>>>>> make much sense of it. I also dug into some of the opto assembly >>>>>> branches trying to map them back into the original bytecode, but it's >>>>>> a very long process -- had to map PcDesc manually to the assembly >>>>>> offset, then go to bytecode again. Then I fired visual studio and >>>>>> halted it like Vladimir mentioned: >>>>>> -XX:AbortVMOnException=java.lang.AssertionError >>>>>> -XX:+ShowMessageBoxOnError >>>>>> >>>>>> Once I attach to the halted JVM I "break all" and I see the reported >>>>>> thread's stack trace halted inside ntdll (with the closest JVM frame >>>>>> stopped at get_deopt_original_pc). The frames below it don't seem to >>>>>> make much sense to me -- they don't seem to point to any addresses >>>>>> reported in the compilation log (PcDesc clauses). I'm a complete >>>>>> newbie to this, so I apologize if it's a lame question, but how can I >>>>>> find out which part of the original jitted code this assertion was >>>>>> invoked from? >>>>>> >>>>>> An ideal scenario and what I want to achieve is I'd like to stop on an >>>>>> assertion somewhere in the jitted code and go back to it to follow the >>>>>> execution (so that I can see what code is responsible for the missing >>>>>> increment). I'll need to sync this up (manually or otherwise) with the >>>>>> optoassembly too, otherwise I'll probably lose any remaining hair >>>>>> trying to figure out what's what :) >>>>>> >>>>>> A hint (or any other pointer; RTFM) would be very welcome. >>>>>> >>>>>> Dawid >>>>>> >>>>>> >>>>>> On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss >>>>>> wrote: >>>>>>> >>>>>>> One follow-up with respect to those encoded integers -- I swapped the >>>>>>> correct and incorrect sequence in my last e-mail, sorry. I then also >>>>>>> added a sysout here: >>>>>>> >>>>>>> @@ -451,6 +453,7 @@ >>>>>>> termFreq = 1; >>>>>>> } else { >>>>>>> termFreq = freq.readVInt(); >>>>>>> + System.err.print("# (tf): " + termFreq + " "); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> With this the assertion is no longer hit but it shows where the >>>>>>> difference in numbers comes from: >>>>>>> >>>>>>> Correct sequence is: >>>>>>> >>>>>>> # (eof) >>>>>>> # (code): 0 >>>>>>> # (tf): 3 >>>>>>> # (code): 4 >>>>>>> # (tf): 3 >>>>>>> # (code): 2 >>>>>>> # (tf): 5 >>>>>>> # (code): 2 >>>>>>> # (tf): 2 >>>>>>> # (code): 3 >>>>>>> # (code): 5 >>>>>>> # (code): 2 >>>>>>> >>>>>>> And the incorrect, assertion-hit run shows: >>>>>>> >>>>>>> # (eof) >>>>>>> # (code): 0 >>>>>>> # (code): 3 >>>>>>> # (code): 4 >>>>>>> # (code): 3 >>>>>>> # (code): 2 >>>>>>> # (code): 5 >>>>>>> # (code): 2 >>>>>>> # (code): 2 >>>>>>> # (code): 3 >>>>>>> >>>>>>> So there's something odd happening after the first readvint which >>>>>>> returns 0 -- the next number that should be read by: >>>>>>> >>>>>>> termFreq = freq.readVInt(); >>>>>>> >>>>>>> is re-read as the next code. >>>>>>> >>>>>>> Dawid >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss >>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks for comments guys. >>>>>>>> >>>>>>>>> It is great that you can build fastdebug VM. I assume that if I give >>>>>>>>> you a >>>>>>>>> patch to try you can also build with it. >>>>>>>> >>>>>>>> >>>>>>>> Yes, absolutely. >>>>>>>> >>>>>>>>> First, you can run with next options and then send zipped output >>>>>>>>> (related >>>>>>>>> part before the method compilation and optoassembler output, don't use >>>>>>>>> hsdis >>>>>>>>> for that) and hs_err file when test fails: >>>>>>>> >>>>>>>> >>>>>>>> I did that. Used the options you requested -- a full log of all I did >>>>>>>> is included in the ZIP file here: >>>>>>>> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >>>>>>>> >>>>>>>> Cat debug-files\debug-log.txt. There are several runs included in that >>>>>>>> ZIP file, in short: >>>>>>>> >>>>>>>> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >>>>>>>> debug-log.txt): >>>>>>>> 001-no-abort-on-assertion >>>>>>>> 002-no-abort-on-assertion >>>>>>>> >>>>>>>> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >>>>>>>> 003-with-abort-on-assertion >>>>>>>> 004-with-abort-on-assertion >>>>>>>> >>>>>>>> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >>>>>>>> 005-hsx-tip >>>>>>>> 006-hsx-tip >>>>>>>> >>>>>>>> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >>>>>>>> build, so only compilation logs available). >>>>>>>> 007-excluded-readvint >>>>>>>> >>>>>>>>> Looking on java code in FreqProxTermsWriterPerField::flush() and based >>>>>>>>> on >>>>>>>>> LUCENE-5168 report generated code somehow missed EOF check. Am I >>>>>>>>> right? This >>>>>>>>> is why the Assert is thrown? >>>>>>>> >>>>>>>> >>>>>>>> It's not the only method it trips on. Depending on the seed the >>>>>>>> problem shows up in different places. For the dumps I included the >>>>>>>> issue seems to be here: >>>>>>>> >>>>>>>>> } else { >>>>>>>>> final int code = freq.readVInt(); >>>>>>>>> if (!readTermFreq) { >>>>>>>>> docID += code; >>>>>>>>> termFreq = -1; >>>>>>>> >>>>>>>> >>>>>>>> If I add sysouts as in: >>>>>>>> >>>>>>>> Index: >>>>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>>>> =================================================================== >>>>>>>> --- >>>>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>>>> (revision 1512807) >>>>>>>> +++ >>>>>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>>>>> (working copy) >>>>>>>> @@ -427,6 +427,7 @@ >>>>>>>> //System.out.println(" cycle"); >>>>>>>> final int termFreq; >>>>>>>> if (freq.eof()) { >>>>>>>> + System.err.print("# (eof)"); >>>>>>>> if (postings.lastDocCodes[termID] != -1) { >>>>>>>> // Return last doc >>>>>>>> docID = postings.lastDocIDs[termID]; >>>>>>>> @@ -442,6 +443,7 @@ >>>>>>>> } >>>>>>>> } else { >>>>>>>> final int code = freq.readVInt(); >>>>>>>> + System.err.print("# (code): " + code + " "); >>>>>>>> if (!readTermFreq) { >>>>>>>> docID += code; >>>>>>>> termFreq = -1; >>>>>>>> >>>>>>>> then for a constant seed you'll get an identical sequence of values. >>>>>>>> Once the assertion hits though, the sequence deviates. Comparing a >>>>>>>> passing run (excluding readvint) and a failing run I get a lot of >>>>>>>> initial aligned outputs and then a deviation: >>>>>>>> >>>>>>>> (correct run): >>>>>>>> # (eof) >>>>>>>> # (eof) >>>>>>>> # (eof) >>>>>>>> # (code): 0 >>>>>>>> # (code): 3 >>>>>>>> # (code): 4 >>>>>>>> # (code): 3 >>>>>>>> >>>>>>>> (incorrect run): >>>>>>>> # (eof) >>>>>>>> # (eof) >>>>>>>> # (eof) >>>>>>>> # (code): 0 >>>>>>>> # (code): 4 <- wtf? >>>>>>>> # (code): 2 >>>>>>>> # (code): 2 >>>>>>>> >>>>>>>> How can a variable encoded integer be misinterpreted from 3 to 4 is >>>>>>>> beyond me, sorry. But it's not an EOF condition I think, at least the >>>>>>>> deviation happens where the original run had was entering (code) >>>>>>>> branch. >>>>>>>> >>>>>>>>> Could you also send latest version of FreqProxTermsWriterPerField.java >>>>>>>>> you >>>>>>>>> are testing? >>>>>>>> >>>>>>>> >>>>>>>> I'm testing against a fixed branch (the info is included in >>>>>>>> debug-log.txt). >>>>>>>> >>>>>>>> If there's anything else I can do, let me know. I'm also curious how >>>>>>>> you approach debugging this thing. It may be time-based so I don't >>>>>>>> think it'll reproduce on your machine out of the box, but who knows. >>>>>>>> All I know is that, for example, if you add one more sysout before the >>>>>>>> while loop it suddenly stops reproducing so probably something gets >>>>>>>> compiled differently... Wild :) >>>>>>>> >>>>>>>> Dawid From erik.helin at oracle.com Fri Sep 6 00:18:04 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 6 Sep 2013 09:18:04 +0200 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <5228AC7A.8030707@oracle.com> References: <20130904173635.GB3989@ehelin-thinkpad> <5228AC7A.8030707@oracle.com> Message-ID: <20130906071804.GB2118@ehelin-thinkpad> On 2013-09-05, Mikael Gerdin wrote: > Erik, > > On 2013-09-04 19:36, Erik Helin wrote: > >Hi all, > > > >this patch changes the name of two flags: > >- -XX:+UseCompressedKlassPointers becomes > > -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') > >- -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize > > > >Background: > >These two flags were introduced when metaspace was merged into hs25. > >To use a smaller size for the Java object headers, the pointer in the > >object header that points to the Klass instance for the object can be 32 > >bits on a 64-bit system. Such pointers has been called compressed klass > >pointers. This is the same concept as compressed oops. > > > >For the current implementation of compressed class pointers to work, the > >Klass instances need to be placed in a continuous virtual memory space. > >This virtual memory space was called ClassMetaspace but this patch > >introduces the name CompressedClassSpace to emphasize that the concept > >is closely related to compressed klass pointers. > > > >The 'K' in the CompressedKlassPointers and CompressedClassSpace was > >changed to a 'C' since the C++ class Klass is an implementation detail > >that we do not want to expose to the users. > > > >I've also added a check in Arguments::parse that checks if the user has > >set CompressedClassSpaceSize when compressed class pointers > >are _not_ used. If this is the case, then the VM will print a warning. I've > >also added a test that verifies this actually happens. > > > >The change touches a lot of files, but the change in each file is very > >small. > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ > > Thanks for taking care of this. > Change looks good to me. Thanks! Erik > /Mikael > > > > >Bug: > >http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 > > > >Testing: > >- JPRT > >- The jtreg tests in hotspot/test > >- Newly added jtreg test > > > >Thanks, > >Erik > > From serguei.spitsyn at oracle.com Fri Sep 6 00:35:10 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 06 Sep 2013 00:35:10 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> <51F7F13E.8040104@oracle.com> <5213C0AA.5030706@oracle.com> Message-ID: <522985AE.2060205@oracle.com> New bug: https://bugs.openjdk.java.net/browse/JDK-8024380 JSR-292: new internal contract between linker primitives and PopFrame is hard to support Thanks! Serguei On 9/4/13 12:01 PM, John Rose wrote: > Yes, please file this bug. I'm working on MH-related optimizations, and I am finding that preserving the required code pattern is blocking some optimizations, notably making customized variations of direct MHs. > > (The required code pattern is that the DMH in Local#0 has a member field which supplies the missing argument to the outgoing linker call. Making a variant DMH with a customized calling sequence is possible, but then it has wrong interactions with the MethodHandleInfo API. It would be easier to make a customized non-DMH, with no member field.) > > ? John > > On Aug 20, 2013, at 12:16 PM, serguei.spitsyn at oracle.com wrote: > >> John, >> >> Thank you for the comments! >> In fact, I was very reluctant to implement it the way as it is in the webrev. >> I'm in favor of the choice #3, and think, it is much better from the stability point of view. >> Restoring the MemberName slot at deoptimization is not going to cause a performance degradation. >> >> If you and Christian are Ok with it I can file a new compiler bug to cover this issue. >> >> Thanks, >> Serguei >> >> >> On 8/12/13 3:30 PM, John Rose wrote: >>> This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes. >>> >>> Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed. >>> >>> In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations. >>> >>> There are other approaches that might be more robust: >>> 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument. >>> 2. Do not make such frames visible to the user. >>> 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization. >>> >>> ? John >>> >>> P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business! >>> >>> On Jul 30, 2013, at 10:00 AM, serguei.spitsyn at oracle.com wrote: >>> >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 7/29/13 10:11 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> I'm fine with restoring to what was in the first webrev. >>>>> >>>>> Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 7/29/13 8:22 PM, David Holmes wrote: >>>>>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Christian and David, >>>>>>>> >>>>>>>> Thank you for the quick review and comments! >>>>>>>> >>>>>>>> This is a new version of webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>>>>>> >>>>>>> Sorry. You need that guard after all - at least you do if you continue >>>>>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>>>>>> will not exist: >>>>>>> >>>>>>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>>>>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>>>>>> >>>>>> You are right, nice catch again. >>>>>> Probably, it was the reason, I did not remove the #if/#endif in the >>>>>> first place. :) >>>>>> >>>>>>> I'm a little surprised that the assembly code does not have that whole >>>>>>> section guarded with INCLUDE_JVMTI - perhaps it should? >>>>>> It should. >>>>>> But it can be non-trivial because of other dependencies like the above. >>>>>> To make it right, both _remove_activation_preserving_args_entry and >>>>>> generate_earlyret_entry_for >>>>>> must be isolated with #if INCLUDE_JVMTI. >>>>>> Then more files have to be involved in this chain of changes: >>>>>> interpreter/templateInterpreter.hpp >>>>>> interpreter/templateInterpreter.hpp >>>>>> memory/universe.hpp >>>>>> memory/universe.cpp >>>>>> code/codeCache.hpp >>>>>> code/codeCache.cpp >>>>>> . . . etc .. >>>>>> >>>>>> Please, note, that the HOTSWAP macro is used in many places as well. >>>>>> I'm not sure we still need it, so that another decision is needed for it. >>>>>> >>>>>> So, it seems that this kind of clean up is going far beyond my fix. >>>>>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >>>>>> platform-dependent files as it was in the webrev v1. >>>>>> I'm a little bit reluctant to open another clean-up bug for this issue >>>>>> but maybe it is needed. >>>>>> Please, let me know if you are comfortable with this solution. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> Run this through a JPRT test build for productEmb to check that the >>>>>>> minimal VM builds ok. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> In the templateInterpreter code why did you put this guard on your new >>>>>>>>> code (from x86_32 version): >>>>>>>>> >>>>>>>>> 1923 #if INCLUDE_JVMTI >>>>>>>>> >>>>>>>>> when the whole chunk of code this is situated in is specifically for >>>>>>>>> JVMTI support >>>>>>>>> >>>>>>>>> 1824 // >>>>>>>>> 1825 // JVMTI PopFrame support >>>>>>>>> 1826 // >>>>>>>>> >>>>>>>>> ??? >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>>>>>> >>>>>>>>>> Description >>>>>>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>>>>>> site >>>>>>>>>> that >>>>>>>>>> takes an appendix and that call site is reexecuted the appendix is >>>>>>>>>> not on >>>>>>>>>> the stack anymore because it got removed by the adapter. >>>>>>>>>> This fix is to detect such a case and push the appendix on the >>>>>>>>>> stack >>>>>>>>>> again before reexecution. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>>>>>> nsk.jdi.testlist >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei From goetz.lindenmaier at sap.com Fri Sep 6 01:21:37 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Sep 2013 08:21:37 +0000 Subject: RFR (S): 8024379: Adapt PPC64 port to 8003424 Message-ID: <4295855A5C1DE049A61835A1887419CC0D018787@DEWDFEMB12A.global.corp.sap> Hi, Syncing 8003424 to the ppc64 staging repository breaks the code so far contributed. This is fixed by this change. http://cr.openjdk.java.net/~goetz/webrevs/8024379/ The change is ppc64 only. Please review this change. I will commit it then before Volker adds the aix changes. Best regards, Goetz From david.holmes at oracle.com Fri Sep 6 01:49:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Sep 2013 18:49:38 +1000 Subject: RFR: 8024256 Minimal VM build is broken with PCH disabled Message-ID: <52299722.5000404@oracle.com> Disabling precompiled headers (PCH) has exposed a number of bugs with the INCLUDE_XXX guards used by the minimal VM. In most cases a header needed to be moved out of the guard or the guards removed. In one case a file can be excluded completely and so its header no longer needs the guard. webrev: http://cr.openjdk.java.net/~dholmes/8024256/webrev/ Thanks, David From coleen.phillimore at oracle.com Fri Sep 6 04:40:46 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 06 Sep 2013 07:40:46 -0400 Subject: RFR: 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <20130906071804.GB2118@ehelin-thinkpad> References: <20130904173635.GB3989@ehelin-thinkpad> <5228AC7A.8030707@oracle.com> <20130906071804.GB2118@ehelin-thinkpad> Message-ID: <5229BF3E.8000700@oracle.com> Erik, Sorry for the delay reviewing this. It looks good. Thank you! Coleen On 9/6/2013 3:18 AM, Erik Helin wrote: > On 2013-09-05, Mikael Gerdin wrote: >> Erik, >> >> On 2013-09-04 19:36, Erik Helin wrote: >>> Hi all, >>> >>> this patch changes the name of two flags: >>> - -XX:+UseCompressedKlassPointers becomes >>> -XX:+UseCompressedClassPointers (note the 'K' instead of the 'C') >>> - -XX:ClassMetaspaceSize becomes -XX:CompressedClassSpaceSize >>> >>> Background: >>> These two flags were introduced when metaspace was merged into hs25. >>> To use a smaller size for the Java object headers, the pointer in the >>> object header that points to the Klass instance for the object can be 32 >>> bits on a 64-bit system. Such pointers has been called compressed klass >>> pointers. This is the same concept as compressed oops. >>> >>> For the current implementation of compressed class pointers to work, the >>> Klass instances need to be placed in a continuous virtual memory space. >>> This virtual memory space was called ClassMetaspace but this patch >>> introduces the name CompressedClassSpace to emphasize that the concept >>> is closely related to compressed klass pointers. >>> >>> The 'K' in the CompressedKlassPointers and CompressedClassSpace was >>> changed to a 'C' since the C++ class Klass is an implementation detail >>> that we do not want to expose to the users. >>> >>> I've also added a check in Arguments::parse that checks if the user has >>> set CompressedClassSpaceSize when compressed class pointers >>> are _not_ used. If this is the case, then the VM will print a warning. I've >>> also added a test that verifies this actually happens. >>> >>> The change touches a lot of files, but the change in each file is very >>> small. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8015107/webrev.00/ >> Thanks for taking care of this. >> Change looks good to me. > Thanks! > > Erik > >> /Mikael >> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015107 >>> >>> Testing: >>> - JPRT >>> - The jtreg tests in hotspot/test >>> - Newly added jtreg test >>> >>> Thanks, >>> Erik >>> From coleen.phillimore at oracle.com Fri Sep 6 04:45:42 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 06 Sep 2013 07:45:42 -0400 Subject: RFR (S): 8024379: Adapt PPC64 port to 8003424 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D018787@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D018787@DEWDFEMB12A.global.corp.sap> Message-ID: <5229C066.7060209@oracle.com> Goetz, This change looks good. There was another .ad file change associated with the new code that you are merging with but I don't know if you have the same code. Coleen On 9/6/2013 4:21 AM, Lindenmaier, Goetz wrote: > Hi, > > Syncing 8003424 to the ppc64 staging repository breaks the code so far > contributed. This is fixed by this change. > http://cr.openjdk.java.net/~goetz/webrevs/8024379/ > > The change is ppc64 only. > > Please review this change. I will commit it then before Volker adds > the aix changes. > > Best regards, > Goetz From coleen.phillimore at oracle.com Fri Sep 6 04:47:08 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 06 Sep 2013 07:47:08 -0400 Subject: RFR: 8024256 Minimal VM build is broken with PCH disabled In-Reply-To: <52299722.5000404@oracle.com> References: <52299722.5000404@oracle.com> Message-ID: <5229C0BC.30205@oracle.com> Looks good. Coleen On 9/6/2013 4:49 AM, David Holmes wrote: > Disabling precompiled headers (PCH) has exposed a number of bugs with > the INCLUDE_XXX guards used by the minimal VM. In most cases a header > needed to be moved out of the guard or the guards removed. In one case > a file can be excluded completely and so its header no longer needs > the guard. > > webrev: http://cr.openjdk.java.net/~dholmes/8024256/webrev/ > > Thanks, > David From goetz.lindenmaier at sap.com Fri Sep 6 05:00:22 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Sep 2013 12:00:22 +0000 Subject: RFR (S): 8024379: Adapt PPC64 port to 8003424 In-Reply-To: <5229C066.7060209@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D018787@DEWDFEMB12A.global.corp.sap> <5229C066.7060209@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D018819@DEWDFEMB12A.global.corp.sap> Hi Coleen, thanks for the review! I know about the changes required in .ad. I don't need them yet, as the compiler stuff is not yet in the staging repository. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 6. September 2013 13:46 To: hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8024379: Adapt PPC64 port to 8003424 Goetz, This change looks good. There was another .ad file change associated with the new code that you are merging with but I don't know if you have the same code. Coleen On 9/6/2013 4:21 AM, Lindenmaier, Goetz wrote: > Hi, > > Syncing 8003424 to the ppc64 staging repository breaks the code so far > contributed. This is fixed by this change. > http://cr.openjdk.java.net/~goetz/webrevs/8024379/ > > The change is ppc64 only. > > Please review this change. I will commit it then before Volker adds > the aix changes. > > Best regards, > Goetz From staffan.larsen at oracle.com Fri Sep 6 06:18:02 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 6 Sep 2013 15:18:02 +0200 Subject: new convention for hsx project repository names In-Reply-To: References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> <21025.7541.995077.658147@oracle.com> Message-ID: <1FC68855-2215-4D88-871A-F8C0DA5C820C@oracle.com> What if there was a one-to-one relationship between HotSpot and the JDK? I think that is the direction we are heading in. /Staffan On 5 sep 2013, at 14:20, Volker Simonis wrote: > In my opinion, your scheme will probably always cause trouble because there > is no one-to-one relation between the HotSpot and JDK version. It would be > hard to guarantee this because there might be always good reasons to > downport a newer HotSpot version into an already released JDK. From harold.seigel at oracle.com Fri Sep 6 06:52:11 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 06 Sep 2013 09:52:11 -0400 Subject: RFR (S): 8024379: Adapt PPC64 port to 8003424 In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D018819@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D018787@DEWDFEMB12A.global.corp.sap> <5229C066.7060209@oracle.com> <4295855A5C1DE049A61835A1887419CC0D018819@DEWDFEMB12A.global.corp.sap> Message-ID: <5229DE0B.9080001@oracle.com> Hi Goetz, Your changes look good. Do you need changes similar to http://cr.openjdk.java.net/~hseigel/bug_8003424.4/src/cpu/x86/vm/vtableStubs_x86_64.cpp.udiff.html because the number of decoding/encoding instructions have increased? Thanks, Harold On 9/6/2013 8:00 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for the review! > I know about the changes required in .ad. I don't need them yet, as > the compiler stuff is not yet in the staging repository. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Freitag, 6. September 2013 13:46 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8024379: Adapt PPC64 port to 8003424 > > > Goetz, > > This change looks good. There was another .ad file change associated > with the new code that you are merging with but I don't know if you have > the same code. > > Coleen > > On 9/6/2013 4:21 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Syncing 8003424 to the ppc64 staging repository breaks the code so far >> contributed. This is fixed by this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8024379/ >> >> The change is ppc64 only. >> >> Please review this change. I will commit it then before Volker adds >> the aix changes. >> >> Best regards, >> Goetz From volker.simonis at gmail.com Fri Sep 6 07:16:17 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 6 Sep 2013 16:16:17 +0200 Subject: new convention for hsx project repository names In-Reply-To: <1FC68855-2215-4D88-871A-F8C0DA5C820C@oracle.com> References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> <21025.7541.995077.658147@oracle.com> <1FC68855-2215-4D88-871A-F8C0DA5C820C@oracle.com> Message-ID: On Fri, Sep 6, 2013 at 3:18 PM, Staffan Larsen wrote: > What if there was a one-to-one relationship between HotSpot and the JDK? I > think that is the direction we are heading in. > That would be an ideal world:) But we shouldn't unnecessarily complicate the process of doing it nevertheless if it is useful or necessary. And developing the HotSpot independently of the JDK with faster release cycles isn't a bad idea in my opinion. As we've seen in JDK7 and especially JDK6 it is possible to deliver quite a lot of benefits to the user with a new VM without having to go trough the heaviweigt process of releasing a new JDK version. > /Staffan > > > On 5 sep 2013, at 14:20, Volker Simonis wrote: > > In my opinion, your scheme will probably always cause trouble because there > is no one-to-one relation between the HotSpot and JDK version. It would be > hard to guarantee this because there might be always good reasons to > downport a newer HotSpot version into an already released JDK. > > From staffan.larsen at oracle.com Fri Sep 6 07:28:39 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 6 Sep 2013 16:28:39 +0200 Subject: new convention for hsx project repository names In-Reply-To: References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> <21025.7541.995077.658147@oracle.com> <1FC68855-2215-4D88-871A-F8C0DA5C820C@oracle.com> Message-ID: <98FB357D-DA26-409C-BEBD-BAE960EFC54C@oracle.com> On 6 sep 2013, at 16:16, Volker Simonis wrote: > On Fri, Sep 6, 2013 at 3:18 PM, Staffan Larsen > wrote: >> What if there was a one-to-one relationship between HotSpot and the JDK? I >> think that is the direction we are heading in. >> > > That would be an ideal world:) Good. > But we shouldn't unnecessarily complicate the process of doing it > nevertheless if it is useful or necessary. > > And developing the HotSpot independently of the JDK with faster > release cycles isn't a bad idea in my opinion. As we've seen in JDK7 > and especially JDK6 it is possible to deliver quite a lot of benefits > to the user with a new VM without having to go trough the heaviweigt > process of releasing a new JDK version. From a customer's point of view I have always found this extremely questionable. The customer applies an update version of the JDK (supposedly containing only bug fixes), but gets a whole new version of he JVM (including many new bugs). I hope instead that we can get the release cycle of the JDK to be fast enough that we can deliver timely Hotspot updates within that cycle. /Staffan From volker.simonis at gmail.com Fri Sep 6 08:09:35 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 6 Sep 2013 17:09:35 +0200 Subject: new convention for hsx project repository names In-Reply-To: <98FB357D-DA26-409C-BEBD-BAE960EFC54C@oracle.com> References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> <21025.7541.995077.658147@oracle.com> <1FC68855-2215-4D88-871A-F8C0DA5C820C@oracle.com> <98FB357D-DA26-409C-BEBD-BAE960EFC54C@oracle.com> Message-ID: On Fri, Sep 6, 2013 at 4:28 PM, Staffan Larsen wrote: > > On 6 sep 2013, at 16:16, Volker Simonis wrote: > >> On Fri, Sep 6, 2013 at 3:18 PM, Staffan Larsen >> wrote: >>> What if there was a one-to-one relationship between HotSpot and the JDK? I >>> think that is the direction we are heading in. >>> >> >> That would be an ideal world:) > > Good. > >> But we shouldn't unnecessarily complicate the process of doing it >> nevertheless if it is useful or necessary. >> >> And developing the HotSpot independently of the JDK with faster >> release cycles isn't a bad idea in my opinion. As we've seen in JDK7 >> and especially JDK6 it is possible to deliver quite a lot of benefits >> to the user with a new VM without having to go trough the heaviweigt >> process of releasing a new JDK version. > > From a customer's point of view I have always found this extremely questionable. > The customer applies an update version of the JDK (supposedly containing > only bug fixes), but gets a whole new version of he JVM (including many new > bugs). > That's of course a problem, but is manageable. But customers are also extremely happy if they get some new features or better performance for free (e.g. the new JSR292 implementation in hsx24 which will be in jdk7u40). And not all JVM features have to be covered by the JCP, most of them are just implementation details. > I hope instead that we can get the release cycle of the JDK to be fast enough > that we can deliver timely Hotspot updates within that cycle. > But the problem is (and believe me, this statement is backed up by experience) that costumers are very reluctant to update to new JDK versions. For many customers even the current release cycles are too fast. They rather update their hardware than updating their software stack. > /Staffan > From john.coomes at oracle.com Fri Sep 6 14:25:36 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Sep 2013 21:25:36 +0000 Subject: hg: hsx/hsx25/hotspot: 58 new changesets Message-ID: <20130906212738.DCAE162616@hg.openjdk.java.net> Changeset: 3f4392035ec7 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3f4392035ec7 Added tag jdk8-b106 for changeset aed585cafc0d ! .hgtags Changeset: c169f7038414 Author: amurillo Date: 2013-08-30 00:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c169f7038414 8024022: new hotspot build - hs25-b49 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 4a1efab850f4 Author: shade Date: 2013-08-26 17:42 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a1efab850f4 8023638: Add the regression test for 8006997 Summary: Add the relevant test and proofread the VM messages as well Reviewed-by: coleenp, mseledtsov, dcubed ! src/share/vm/runtime/arguments.cpp + test/runtime/contended/Options.java Changeset: a7d8baf4cca7 Author: dcubed Date: 2013-08-26 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a7d8baf4cca7 Merge Changeset: 91b93f523ec6 Author: acorn Date: 2013-08-26 11:35 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/91b93f523ec6 8012294: remove generic handling for default methods Reviewed-by: kamg, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/globals.hpp Changeset: d80493ee6430 Author: acorn Date: 2013-08-27 01:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d80493ee6430 Merge - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/globals.hpp Changeset: 6b3ac96bada6 Author: jiangli Date: 2013-08-26 13:32 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b3ac96bada6 8023477: Invalid CP index when reading ConstantPool. Summary: Need to check for 0 case for InstanceKlass::_generic_signature_index. Reviewed-by: sspitsyn, sla ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java Changeset: b3596321fbf4 Author: jiangli Date: 2013-08-27 04:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b3596321fbf4 Merge Changeset: 7e7dd25666da Author: ccheung Date: 2013-08-26 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7e7dd25666da 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error Summary: removed offending EXCEPTION_MARK calls and code cleanup Reviewed-by: dholmes, iklam, coleenp, mseledtsov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp + test/runtime/LoadClass/LoadClassNegative.java + test/runtime/LoadClass/TestForName.java + test/runtime/LoadClass/dummy.jar Changeset: 5351fe805c12 Author: minqi Date: 2013-08-27 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5351fe805c12 Merge Changeset: f462e61bce87 Author: iklam Date: 2013-08-26 21:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f462e61bce87 8020622: create.bat on Windows failed to create project file for Visual Studio 2012 Summary: Treat VS2012 the same as VS2010. Reviewed-by: dcubed, kamg, minqi ! make/windows/create.bat ! make/windows/makefiles/rules.make Changeset: 35471dcba316 Author: iklam Date: 2013-08-27 03:35 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/35471dcba316 Merge Changeset: c26d57fa08aa Author: iklam Date: 2013-08-27 16:02 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c26d57fa08aa Merge Changeset: 915cc4f3fb15 Author: acorn Date: 2013-08-28 08:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/915cc4f3fb15 8020489: VM crash when non-existent interface called by invokespecial Reviewed-by: kamg, coleenp ! src/share/vm/classfile/defaultMethods.cpp Changeset: cc56f122f3f7 Author: sla Date: 2013-08-29 11:05 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cc56f122f3f7 8023720: (hotspot) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes, rbackman ! src/os/posix/vm/os_posix.cpp Changeset: 76482cbba706 Author: hseigel Date: 2013-08-29 10:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/76482cbba706 8016764: JVM does not prohibit invokespecial in c.f.v 51.0 that invokes default interface method in c.f.v 52.0 Summary: Check cfv before allowing invokespecial call to default method. Reviewed-by: kamg, acorn, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: dfc126b2f659 Author: hseigel Date: 2013-08-29 13:44 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dfc126b2f659 8022407: sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35 Summary: lower optimization level for unsafe.cpp due to MacOS Xcode 4.6.2 compiler optimization issue. Reviewed-by: coleenp, twisti, dholmes Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/gcc.make Changeset: d8e99408faad Author: dsamersoff Date: 2013-08-29 21:48 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d8e99408faad 8009062: poor performance of JNI AttachCurrentThread after fix for 7017193 Summary: don't re-evaluate stack bounds for main thread before install guard page Reviewed-by: coleenp, dholmes, dlong ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + test/runtime/InitialThreadOverflow/DoOverflow.java + test/runtime/InitialThreadOverflow/invoke.cxx + test/runtime/InitialThreadOverflow/testme.sh Changeset: cef1e56a4d88 Author: dsamersoff Date: 2013-08-29 21:46 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cef1e56a4d88 Merge Changeset: 9758d9f36299 Author: coleenp Date: 2013-08-29 18:56 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9758d9f36299 8021954: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced Summary: declare all user-defined operator new()s within Hotspot code with the empty throw() exception specification Reviewed-by: coleenp, twisti, dholmes, hseigel, dcubed, kvn, ccheung Contributed-by: lois.foltan at oracle.com ! src/share/vm/adlc/arena.cpp ! src/share/vm/adlc/arena.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/park.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/utilities/array.hpp Changeset: c636758ea616 Author: dcubed Date: 2013-08-30 07:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c636758ea616 Merge ! src/os/posix/vm/os_posix.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 522d69638aa8 Author: zgu Date: 2013-08-30 11:54 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/522d69638aa8 6991327: using -Xprof trigger native memory leak Summary: Fixed a memory leak in FlatProfiler::record_thread_tick() method Reviewed-by: dholmes, ccheung ! src/share/vm/runtime/fprofiler.cpp Changeset: 491de79915eb Author: zgu Date: 2013-08-30 12:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/491de79915eb Merge ! src/share/vm/runtime/fprofiler.cpp Changeset: ac2764460da7 Author: zgu Date: 2013-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ac2764460da7 Merge Changeset: ca0501b58953 Author: hseigel Date: 2013-08-30 15:07 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca0501b58953 8024050: Incorrect optimization level and comment specified for unsafe.cpp Summary: Fix comments and optimization level. Reviewed-by: rdurbin, coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/gcc.make Changeset: d8ff06fb87ae Author: hseigel Date: 2013-08-30 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d8ff06fb87ae Merge Changeset: abff50660360 Author: hseigel Date: 2013-08-30 15:57 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/abff50660360 Merge Changeset: 3a1df0dce3e5 Author: acorn Date: 2013-08-30 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a1df0dce3e5 8023872: Verification error in generated lambda classes Summary: skip verification for generated lambda classes Reviewed-by: kamg, dholmes ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: 735f94656acc Author: acorn Date: 2013-08-30 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/735f94656acc Merge Changeset: 2918c7e21a3a Author: acorn Date: 2013-08-30 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2918c7e21a3a Merge Changeset: 35b99e7e0af2 Author: hseigel Date: 2013-09-01 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/35b99e7e0af2 8023381: VM fails to initialize in runtime/CDSCompressedKPtrs/XShareAuto.java runtime/SharedArchiveFile/CdsSameObjectAlignment.java Summary: Improve handling when CDS archive cannot be mapped Reviewed-by: kvn, dholmes, mseledtsov ! src/share/vm/memory/filemap.cpp ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java Changeset: 766fac3395d6 Author: kvn Date: 2013-08-23 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/766fac3395d6 8012972: Incremental Inlining should support scalar replaced object in debug info Summary: store in _first_index not absolute index but an index relative to the last (youngest) jvms->_scloff value Reviewed-by: roland, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: b17d8f6d9ed7 Author: kvn Date: 2013-08-23 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b17d8f6d9ed7 8023472: C2 optimization breaks with G1 Summary: set control edge for previous value load in G1 pre-barrier Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp + test/compiler/gcbarriers/G1CrashTest.java Changeset: f98f5d48f511 Author: roland Date: 2013-08-21 13:34 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f98f5d48f511 7199175: JSR 292: C1 needs patching when invokedynamic/invokehandle call site is not linked Summary: Do patching rather bailing out for unlinked call with appendix Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: e1fbb86b47e4 Author: roland Date: 2013-08-26 16:12 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e1fbb86b47e4 8016277: Crash in nmethod::is_compiled_by_c1() on x86 Summary: Method pointer for zombie methods may be invalid Reviewed-by: kvn, coleenp ! src/share/vm/code/nmethod.cpp Changeset: e47de6dfec5d Author: vlivanov Date: 2013-08-26 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e47de6dfec5d 8022456: LogCompilation tool does not work with C1 output again Reviewed-by: kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: 74608df95ba3 Author: vlivanov Date: 2013-08-26 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/74608df95ba3 8022595: JSR292: deadlock during class loading of MethodHandles, MethodHandleImpl & MethodHandleNatives Reviewed-by: kvn, coleenp, dholmes ! src/share/vm/runtime/thread.cpp + test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 022415fe638e Author: vlivanov Date: 2013-08-26 21:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/022415fe638e Merge Changeset: 59982ff9e0ec Author: rbackman Date: 2013-08-20 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/59982ff9e0ec 8022283: Assertion failed: assert(is_loaded() && field->holder()->is_loaded() && klass()->is_subclass_of (field->holder())) failed: invalid access Reviewed-by: roland, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstance.cpp Changeset: 58e010ab2d06 Author: rbackman Date: 2013-08-27 19:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/58e010ab2d06 Merge Changeset: 650868c062a9 Author: adlertz Date: 2013-08-26 12:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/650868c062a9 8023691: Create interface for nodes in class Block Summary: Create public methods for accessing the nodes in a block Reviewed-by: kvn, roland ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp Changeset: 7181dd13a6c4 Author: adlertz Date: 2013-08-27 21:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7181dd13a6c4 Merge Changeset: 29aa8936f03c Author: kvn Date: 2013-08-28 11:22 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/29aa8936f03c 8023597: Optimize G1 barriers code for unsafe load_store Summary: Avoid loading old values in G1 pre-barriers for inlined unsafe load_store nodes. Reviewed-by: kvn, tonyp Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp Changeset: 8947af8a9cec Author: vlivanov Date: 2013-08-29 22:44 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8947af8a9cec 8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check Reviewed-by: kvn, twisti ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4b078f877b56 Author: adlertz Date: 2013-09-01 19:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4b078f877b56 8023988: Move local scheduling of nodes to the CFG creation and code motion phase (PhaseCFG) Summary: Moved local scheduling code from class Block to class PhaseCFG Reviewed-by: kvn, roland ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 40ed2dc92a79 Author: adlertz Date: 2013-09-01 19:52 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/40ed2dc92a79 Merge Changeset: 27ffd1c4537b Author: rbackman Date: 2013-09-02 13:13 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/27ffd1c4537b Merge ! src/share/vm/runtime/thread.cpp Changeset: a9a968364704 Author: adlertz Date: 2013-09-02 22:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a9a968364704 8024095: Missing brackets in local scheduling code. Summary: Added brackets for if-statement Reviewed-by: kvn, roland ! src/share/vm/opto/lcm.cpp Changeset: 3bfb204913de Author: adlertz Date: 2013-09-05 10:39 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3bfb204913de Merge ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/node.hpp Changeset: 88c255656030 Author: mgerdin Date: 2013-08-22 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/88c255656030 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld Summary: When using NUMA and large pages we need to ease the requirement on which node the memory should be allocated on. To avoid the SIGBUS we now use the memory policy MPOL_PREFERRED, which prefers a certain node, instead of MPOL_BIND, which requires a certain node. Reviewed-by: jmasa, pliden Contributed-by: stefan.johansson at oracle.com ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 0d59407e7e09 Author: jmasa Date: 2013-08-29 06:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0d59407e7e09 Merge ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 84683e78e713 Author: brutisso Date: 2013-08-30 07:31 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/84683e78e713 8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size Reviewed-by: tonyp, tschatzl, sjohanss ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: f175e3678be2 Author: ehelin Date: 2013-08-22 11:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f175e3678be2 8020692: TestGCEventMixed.java failed because of timestamp in event after end event Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp Changeset: a701c16e8bbf Author: jmasa Date: 2013-09-04 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a701c16e8bbf 8013938: Native OOME on fastdebug VM on Solaris Reviewed-by: azeemj, brutisso, kvn, tschatzl ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 428025878417 Author: jmasa Date: 2013-09-04 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/428025878417 Merge Changeset: bb57d48691f5 Author: tschatzl Date: 2013-09-05 14:15 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bb57d48691f5 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 50794d8ac11c Author: amurillo Date: 2013-09-06 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/50794d8ac11c Merge - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp Changeset: 5b7f90aab3ad Author: amurillo Date: 2013-09-06 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5b7f90aab3ad Added tag hs25-b49 for changeset 50794d8ac11c ! .hgtags From john.coomes at oracle.com Fri Sep 6 16:17:50 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Sep 2013 23:17:50 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130906231800.D78286261D@hg.openjdk.java.net> Changeset: 3f4392035ec7 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3f4392035ec7 Added tag jdk8-b106 for changeset aed585cafc0d ! .hgtags Changeset: 50794d8ac11c Author: amurillo Date: 2013-09-06 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/50794d8ac11c Merge - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp Changeset: 5b7f90aab3ad Author: amurillo Date: 2013-09-06 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5b7f90aab3ad Added tag hs25-b49 for changeset 50794d8ac11c ! .hgtags Changeset: 313b724f8911 Author: amurillo Date: 2013-09-06 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/313b724f8911 8024258: new hotspot build - hs25-b50 Reviewed-by: jcoomes ! make/hotspot_version From goetz.lindenmaier at sap.com Mon Sep 9 01:42:36 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Sep 2013 08:42:36 +0000 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. Message-ID: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> Hi, This is the first of about 10 changes taking us to a rudimentary c2 compiler on ppc64. Some platforms, as ppc and s390x/zArch require that 32-bit ints are passed as 64-bit values to C functions. This change adds support to adapt the signature and to issue proper casts to c2-compiled stubs. The functions are used in generate_native_wrapper(). We also need to adapt the signature in PhaseIdealLoop::intrinsify_fill(). We add a function c_calling_convention_requires_ints_as_longs() to the platform files of sharedRuntime, with enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by ifdef COMPILER2). See http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp line 1752 ff. http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ Please review and test this change. Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Sep 9 02:41:14 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Sep 2013 09:41:14 +0000 Subject: RFR(M): 8024344: PPC64 (part 112): C argument in register AND stack slot. Message-ID: <4295855A5C1DE049A61835A1887419CC0D019FA3@DEWDFEMB12A.global.corp.sap> Hi, On PPC, the first 13 floating point arguments are passed in floating point registers. Also, all but the first 8 arguments are passed on the stack. So there can be floating point arguments that are passed on the stack and in a register. This change adapts the c_calling_conventions() to this. We duplicate the regs datastructure passed to c_calling_convention(). This change adapts all the signatures of this function, which is defined in a shared file, but implemented platform dependent. How we use this can be seen in the ppc64 sharedRuntime file in function c_calling_convention() and the stub generators. http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp Please review and test this change. http://cr.openjdk.java.net/~goetz/webrevs/8024344-stackArg/ Best regards, Goetz. From vladimir.x.ivanov at oracle.com Mon Sep 9 04:24:37 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 09 Sep 2013 15:24:37 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) Message-ID: <522DAFF5.3030905@oracle.com> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ 7 lines changed: 4 ins; 0 del; 3 mod Added pid of the Java process to default name of VM log file: - old: hotspot.log - new: hotspot_pid{pid}.log It allows to avoid hotspot.log overwrite/corruption in multi-VM test scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Mon Sep 9 09:59:02 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 09 Sep 2013 09:59:02 -0700 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522DAFF5.3030905@oracle.com> References: <522DAFF5.3030905@oracle.com> Message-ID: <522DFE56.7020106@oracle.com> Vladimir, Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on both branches. There are several comments in sources which mention hotspot.log. I think they need to be changes. Especially in globals.hpp Thanks, Vladimir K On 9/9/13 4:24 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ > 7 lines changed: 4 ins; 0 del; 3 mod > > Added pid of the Java process to default name of VM log file: > - old: hotspot.log > - new: hotspot_pid{pid}.log > > It allows to avoid hotspot.log overwrite/corruption in multi-VM test scenarios and simplifies > hs_err/ciReplay/hotspot.log files matching. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Mon Sep 9 10:27:34 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 09 Sep 2013 21:27:34 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522DFE56.7020106@oracle.com> References: <522DAFF5.3030905@oracle.com> <522DFE56.7020106@oracle.com> Message-ID: <522E0506.5030106@oracle.com> Vladimir K., Thanks for looking into this. How about this? http://cr.openjdk.java.net/~vlivanov/8023134/webrev.01 Best regards, Vladimir Ivanov On 9/9/13 8:59 PM, Vladimir Kozlov wrote: > Vladimir, > > Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on > both branches. > There are several comments in sources which mention hotspot.log. I think > they need to be changes. Especially in globals.hpp > > Thanks, > Vladimir K > > On 9/9/13 4:24 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> Added pid of the Java process to default name of VM log file: >> - old: hotspot.log >> - new: hotspot_pid{pid}.log >> >> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >> scenarios and simplifies >> hs_err/ciReplay/hotspot.log files matching. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From mattis.castegren at oracle.com Mon Sep 9 10:38:33 2013 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Mon, 9 Sep 2013 10:38:33 -0700 (PDT) Subject: FW: Project to improve hs_err files Message-ID: Hi. I sent this email to serviceability and runtime, but I got a request to forward the mail to all of hotspot dev as hs_err files affects all areas. Please let me know if you have any feedback. Don't worry about if the suggestions are feasible or not, that will come in a second step. From: Mattis Castegren Sent: den 6 september 2013 13:32 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Cc: Mattis Castegren Subject: Project to improve hs_err files Hi (re-sending mail after joining the mailing lists, sorry if you get this mail twice) My name is Mattis and I work with the JVM sustaining engineering team at Oracle. I am starting up a project to improve the data we get in the hs_err files when the JVM crashes. I have filed a JEP, but it has not yet been approved. See my attachment for the initial draft including motivation and scope. The main goal is not to completely solve new bugs by just using an hs_err file, but to help users, support and development to debug their problems, find duplicates of fixed bugs or application errors. It is also to provide more information that can be helpful when doing core file debugging on new issues. The first step in this project is to gather suggestions of data that could help us when we see crashes. I am talking to the rest of the sustaining engineering team and also to the Java support team, but I also wanted to ask if anyone on these aliases have any thoughts on what data would help when we get an hs_err file. I'm looking for both big and small suggestions. Deciding if the suggestions are feasible or not can be discussed later. Suggestions so far: * Bigger changes - Re-structure hs_err file to put more important data first, maybe include a summary header. End users can't be expected to read through the entire hs_err file. If we can put important hints of what went wrong at the top, that could save a lot of time. Also, many web tools truncate hs_err files, so we may never see the end of the files. This would also help us to faster triage incoming incidents - Look at context sensitive data. If we crash when compiling a method, what additional data could we provide. Can we provide anything when crashing in GC, or when running interpreted code? - Could we verify data structures? If we could list that some GC table had been corrupted, that could give a hint at the problem as well as help with finding duplicates and known issues - Suggest workarounds/first debug steps. Sometimes we immediately know what the first debug step is. If we crash when running a compiled method, try to disable compilation of that method. If we crash after several OOMs, try increasing the Java heap or lower heap usage. If we could print these first steps, this could lead to bug filers providing more data when they file a bug. We could also highlight "dangerous" options, like -Xverify:none * Additional Data - The GC Strategy used - The classpath variable - Have we seen any OutOfMemoryErrors, StackOverflowErrors or C Heap allocation fails? - Include Hypervisor information. If we run on Xen or VMWare, that is very interesting data - Heap usage and permgen usage (JDK7) after the last full GC. If the heap is 99% full, that is a good hint that we might have run into a corner case in OOM handling for example - Write the names of the last exceptions thrown. We currently list the addresses of the last exceptions. Giving the type instead would be very good. Did we crash after 10 StackOverflowErrors? That's a good hint of what went wrong - Make the GC Heap History more easy to read. It's a great feature, but it is somewhat hard to read if an event is a full GC or a YC etc. - Assembler instructions in dump files. Right now, we print the code around the IP in hex format. This isn't very helpful. If we could get the crashing instructions as assembler instead, that would help a lot - Growing and shrinking of heap. We have seen a few issues when growing or shrinking the java heap. Saving the last few increases and decreases with a timestamp would help finding out if this could be an issue - Highlight if third party JNI libs have been used Please let me know if you have ideas of what information would make hs_err files more useful, and I will add them to my list. Kind Regards /Mattis -------------- next part -------------- Title: Include more useful information in hs_err files Author: Mattis Castegren Organization: Oracle Owner: Mattis Castegren Created: 2013/9/27 Type: Feature State: Draft Exposure: Open Component: vm/svc Scope: Impl JSR: RFE: Discussion: serviceability dash dev at openjdk dot java dot net Start: 2013/Q2 Depends: Blocks: Effort: S Duration: L Template: 1.0 Internal-refs: Reviewed-by: Endorsed-by: Funded-by: Summary ------- Work to get more useful data in hs_err files, to make it easier for customers, support and development to find the reason of crashes without core file debugging. Work to point out common issues like OOMs and SOEs, and make it easier to verify known issues. Goals ----- Many of the Java Incidents and test failures that come in are about crashes, and have little more information than an hs_err file. If we can point out common problems and include more debug information in the hs_err files, that could save a lot of work. If the header of an hs_err file says that "you have had 1400 OutOfMemoryErrors before the crash", the user can start by investigating these issues. The focus of this project should be both advanced users, like Dev or Sustaining Engineering, and regular users who see a crash in some application. The output must therefore be easy to understand, yet contain enough detail for advanced debugging. Non-Goals --------- The goal is not to find new bugs using only an hs_err file. This project may help in some cases, but if it's really a new bug we will usually need a core file or a reproducer. Success Metrics --------------- Motivation ---------- We get thousands of Crash Reports against Java. By including better information in the hs_err files, we can easily filter out bugs caused by user errors, known issues, etc. Better hs_err files will also allow more bugs to be resolved either by the customer or by support, leading to lower costs in both the support organization and the development organizations Description ----------- The first part of this project should be to investigate what information would help Dev, Sustaining and Support. We should look at solved crashes and see what information would have helped. We should also see what crashes turns out to be caused by user errors. This should be done at both the jvm, core and client areas, as all teams run into crashes. For core and client, these crashes are more often in the native libraries. This investigation should result in several enhancement requests. Each of these can then be discussed independently on the open jdk aliases. Alternatives ------------ Testing ------- Testing can be difficult, as we will sometimes add features to make other debugging easier. Some of the features may therefore be hard to test if there are no known ways to trigger the problem. We should run any testing we do have for hs_err files to make sure that the new features don't interfere with what is already there. Risks and Assumptions --------------------- The risks of these features will be small. When they are triggered, the program is already crashed. The biggest risk is that the new features may in turn contain bugs that could cause the hs_err files to be truncated, giving even less information instead of more. Dependencies ----------- Impact ------ Low, should only be noticeable when Java crashes. From vladimir.kozlov at oracle.com Mon Sep 9 10:59:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 09 Sep 2013 10:59:48 -0700 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522E0506.5030106@oracle.com> References: <522DAFF5.3030905@oracle.com> <522DFE56.7020106@oracle.com> <522E0506.5030106@oracle.com> Message-ID: <522E0C94.3000903@oracle.com> You missed LogCompilation/README, otherwise it is good. Thanks, Vladimir On 9/9/13 10:27 AM, Vladimir Ivanov wrote: > Vladimir K., > > Thanks for looking into this. > > How about this? > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.01 > > Best regards, > Vladimir Ivanov > > On 9/9/13 8:59 PM, Vladimir Kozlov wrote: >> Vladimir, >> >> Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on >> both branches. >> There are several comments in sources which mention hotspot.log. I think >> they need to be changes. Especially in globals.hpp >> >> Thanks, >> Vladimir K >> >> On 9/9/13 4:24 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>> 7 lines changed: 4 ins; 0 del; 3 mod >>> >>> Added pid of the Java process to default name of VM log file: >>> - old: hotspot.log >>> - new: hotspot_pid{pid}.log >>> >>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>> scenarios and simplifies >>> hs_err/ciReplay/hotspot.log files matching. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Mon Sep 9 13:01:35 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 10 Sep 2013 00:01:35 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522E0C94.3000903@oracle.com> References: <522DAFF5.3030905@oracle.com> <522DFE56.7020106@oracle.com> <522E0506.5030106@oracle.com> <522E0C94.3000903@oracle.com> Message-ID: <522E291F.6050209@oracle.com> Thanks for catching this! Updated the webrev. Best regards, Vladimir Ivanov On 9/9/13 9:59 PM, Vladimir Kozlov wrote: > You missed LogCompilation/README, otherwise it is good. > > Thanks, > Vladimir > > On 9/9/13 10:27 AM, Vladimir Ivanov wrote: >> Vladimir K., >> >> Thanks for looking into this. >> >> How about this? >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.01 >> >> Best regards, >> Vladimir Ivanov >> >> On 9/9/13 8:59 PM, Vladimir Kozlov wrote: >>> Vladimir, >>> >>> Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on >>> both branches. >>> There are several comments in sources which mention hotspot.log. I think >>> they need to be changes. Especially in globals.hpp >>> >>> Thanks, >>> Vladimir K >>> >>> On 9/9/13 4:24 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>> >>>> Added pid of the Java process to default name of VM log file: >>>> - old: hotspot.log >>>> - new: hotspot_pid{pid}.log >>>> >>>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>>> scenarios and simplifies >>>> hs_err/ciReplay/hotspot.log files matching. >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Mon Sep 9 13:13:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 09 Sep 2013 13:13:13 -0700 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522E291F.6050209@oracle.com> References: <522DAFF5.3030905@oracle.com> <522DFE56.7020106@oracle.com> <522E0506.5030106@oracle.com> <522E0C94.3000903@oracle.com> <522E291F.6050209@oracle.com> Message-ID: <522E2BD9.2060709@oracle.com> Good. Thanks, Vladimir K On 9/9/13 1:01 PM, Vladimir Ivanov wrote: > Thanks for catching this! Updated the webrev. > > Best regards, > Vladimir Ivanov > > On 9/9/13 9:59 PM, Vladimir Kozlov wrote: >> You missed LogCompilation/README, otherwise it is good. >> >> Thanks, >> Vladimir >> >> On 9/9/13 10:27 AM, Vladimir Ivanov wrote: >>> Vladimir K., >>> >>> Thanks for looking into this. >>> >>> How about this? >>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.01 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 9/9/13 8:59 PM, Vladimir Kozlov wrote: >>>> Vladimir, >>>> >>>> Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on >>>> both branches. >>>> There are several comments in sources which mention hotspot.log. I think >>>> they need to be changes. Especially in globals.hpp >>>> >>>> Thanks, >>>> Vladimir K >>>> >>>> On 9/9/13 4:24 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>> >>>>> Added pid of the Java process to default name of VM log file: >>>>> - old: hotspot.log >>>>> - new: hotspot_pid{pid}.log >>>>> >>>>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>>>> scenarios and simplifies >>>>> hs_err/ciReplay/hotspot.log files matching. >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From yumin.qi at oracle.com Mon Sep 9 15:45:41 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 09 Sep 2013 15:45:41 -0700 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <522E4F95.2020407@oracle.com> Vote: yes On 8/29/2013 11:36 AM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From david.holmes at oracle.com Mon Sep 9 19:19:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Sep 2013 12:19:32 +1000 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522E291F.6050209@oracle.com> References: <522DAFF5.3030905@oracle.com> <522DFE56.7020106@oracle.com> <522E0506.5030106@oracle.com> <522E0C94.3000903@oracle.com> <522E291F.6050209@oracle.com> Message-ID: <522E81B4.5050601@oracle.com> Minor nit in pre-existing text: diagnostic(ccstr, LogFile, NULL, \ ! "If LogVMOutput is on, save VM output to this file " should say "If LogVMOutput or LogCompilation is on, ..." David On 10/09/2013 6:01 AM, Vladimir Ivanov wrote: > Thanks for catching this! Updated the webrev. > > Best regards, > Vladimir Ivanov > > On 9/9/13 9:59 PM, Vladimir Kozlov wrote: >> You missed LogCompilation/README, otherwise it is good. >> >> Thanks, >> Vladimir >> >> On 9/9/13 10:27 AM, Vladimir Ivanov wrote: >>> Vladimir K., >>> >>> Thanks for looking into this. >>> >>> How about this? >>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.01 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 9/9/13 8:59 PM, Vladimir Kozlov wrote: >>>> Vladimir, >>>> >>>> Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on >>>> both branches. >>>> There are several comments in sources which mention hotspot.log. I >>>> think >>>> they need to be changes. Especially in globals.hpp >>>> >>>> Thanks, >>>> Vladimir K >>>> >>>> On 9/9/13 4:24 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>> >>>>> Added pid of the Java process to default name of VM log file: >>>>> - old: hotspot.log >>>>> - new: hotspot_pid{pid}.log >>>>> >>>>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>>>> scenarios and simplifies >>>>> hs_err/ciReplay/hotspot.log files matching. >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Sep 10 01:43:19 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 10 Sep 2013 12:43:19 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522E81B4.5050601@oracle.com> References: <522DAFF5.3030905@oracle.com> <522DFE56.7020106@oracle.com> <522E0506.5030106@oracle.com> <522E0C94.3000903@oracle.com> <522E291F.6050209@oracle.com> <522E81B4.5050601@oracle.com> Message-ID: <522EDBA7.8060604@oracle.com> David, thanks for review. Best regards, Vladimir Ivanov On 9/10/13 6:19 AM, David Holmes wrote: > Minor nit in pre-existing text: > > diagnostic(ccstr, LogFile, NULL, \ > ! "If LogVMOutput is on, save VM output to this file " > > should say "If LogVMOutput or LogCompilation is on, ..." > > David > > On 10/09/2013 6:01 AM, Vladimir Ivanov wrote: >> Thanks for catching this! Updated the webrev. >> >> Best regards, >> Vladimir Ivanov >> >> On 9/9/13 9:59 PM, Vladimir Kozlov wrote: >>> You missed LogCompilation/README, otherwise it is good. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/9/13 10:27 AM, Vladimir Ivanov wrote: >>>> Vladimir K., >>>> >>>> Thanks for looking into this. >>>> >>>> How about this? >>>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.01 >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 9/9/13 8:59 PM, Vladimir Kozlov wrote: >>>>> Vladimir, >>>>> >>>>> Move last FREE_C_HEAP_ARRAY() after 'if' body instead of having it on >>>>> both branches. >>>>> There are several comments in sources which mention hotspot.log. I >>>>> think >>>>> they need to be changes. Especially in globals.hpp >>>>> >>>>> Thanks, >>>>> Vladimir K >>>>> >>>>> On 9/9/13 4:24 AM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>>> >>>>>> Added pid of the Java process to default name of VM log file: >>>>>> - old: hotspot.log >>>>>> - new: hotspot_pid{pid}.log >>>>>> >>>>>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>>>>> scenarios and simplifies >>>>>> hs_err/ciReplay/hotspot.log files matching. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov From staffan.larsen at oracle.com Tue Sep 10 04:31:34 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Sep 2013 14:31:34 +0300 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522DAFF5.3030905@oracle.com> References: <522DAFF5.3030905@oracle.com> Message-ID: I'm not sure this change is only to the better. Since every run of a debug-build of hotspot creates this file, there is now going to be an enormous amount of these files create. At least for me that is going to be a big nuisance since they will clutter up every directory where I run hotspot. Would it be possible to keep hotspot.log as the default name, and have a flag which multiprocess tests can use to include the pid in the name? /Staffan On 9 sep 2013, at 14:24, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ > 7 lines changed: 4 ins; 0 del; 3 mod > > Added pid of the Java process to default name of VM log file: > - old: hotspot.log > - new: hotspot_pid{pid}.log > > It allows to avoid hotspot.log overwrite/corruption in multi-VM test scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. > > Thanks! > > Best regards, > Vladimir Ivanov From bengt.rutisson at oracle.com Tue Sep 10 05:31:44 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 10 Sep 2013 14:31:44 +0200 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: References: <522DAFF5.3030905@oracle.com> Message-ID: <522F1130.8050900@oracle.com> On 9/10/13 1:31 PM, Staffan Larsen wrote: > I'm not sure this change is only to the better. Since every run of a debug-build of hotspot creates this file, there is now going to be an enormous amount of these files create. At least for me that is going to be a big nuisance since they will clutter up every directory where I run hotspot. Would it be possible to keep hotspot.log as the default name, and have a flag which multiprocess tests can use to include the pid in the name? I agree with Staffan. This seems to be a quite invasive change in the sense that it will create lots of files in our test and development environments. In fact, isn't it possible for the multiprocess tests that have issues to just specify the LogFile as: -XX:LogFile=hotspot_pid%p.log That wouldn't require any changes to the VM at all. Thanks, Bengt > > /Staffan > > On 9 sep 2013, at 14:24, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> Added pid of the Java process to default name of VM log file: >> - old: hotspot.log >> - new: hotspot_pid{pid}.log >> >> It allows to avoid hotspot.log overwrite/corruption in multi-VM test scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From stefan.johansson at oracle.com Tue Sep 10 06:19:46 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 10 Sep 2013 15:19:46 +0200 Subject: RFR: 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 Message-ID: <522F1C72.1080906@oracle.com> Hi all, Please review this really small fix for a test failure on Mac. Webrev: http://cr.openjdk.java.net/~sjohanss/8024176/webrev.00/ Summary: A GC jtreg test fails on Mac, and when looking at the failure one can see that the SA fails to find the type for an oop. It turns out the code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden since compressed oops and compressed klasses has used the same base address. This was recently changed and now the SA agent will show this issue when attached to a JVM using compressed klasses. The patch: --- old/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java 2013-09-10 13:52:17.163078372 +0200 +++ new/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java 2013-09-10 13:52:17.079078971 +0200 @@ -81,7 +81,7 @@ public Address getCompKlassAddressAt(long offset) throws UnalignedAddressException, UnmappedAddressException { - return debugger.readCompOopAddress(addr + offset); + return debugger.readCompKlassAddress(addr + offset); } // Thanks, Stefan From staffan.larsen at oracle.com Tue Sep 10 07:11:53 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Sep 2013 17:11:53 +0300 Subject: RFR: 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 In-Reply-To: <522F1C72.1080906@oracle.com> References: <522F1C72.1080906@oracle.com> Message-ID: <9A08A580-6358-447A-9D90-BBE69D85EB19@oracle.com> Looks good! /Staffan On 10 sep 2013, at 16:19, Stefan Johansson wrote: > Hi all, > > Please review this really small fix for a test failure on Mac. > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8024176/webrev.00/ > > Summary: > A GC jtreg test fails on Mac, and when looking at the failure one can see that the SA fails to find the type for an oop. It turns out the code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden since compressed oops and compressed klasses has used the same base address. This was recently changed and now the SA agent will show this issue when attached to a JVM using compressed klasses. > > The patch: > > --- old/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java 2013-09-10 13:52:17.163078372 +0200 > +++ new/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java 2013-09-10 13:52:17.079078971 +0200 > @@ -81,7 +81,7 @@ > public Address getCompKlassAddressAt(long offset) > throws UnalignedAddressException, UnmappedAddressException { > - return debugger.readCompOopAddress(addr + offset); > + return debugger.readCompKlassAddress(addr + offset); > } > // > > > Thanks, > Stefan From volker.simonis at gmail.com Tue Sep 10 08:25:27 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Sep 2013 17:25:27 +0200 Subject: RFR(M): 8024344: PPC64 (part 112): C argument in register AND stack slot. In-Reply-To: <522E20F0.1000102@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D019FA3@DEWDFEMB12A.global.corp.sap> <522E20F0.1000102@oracle.com> Message-ID: Hi Chris, I think it is hard to find a real authoritative documentation for this convention. But GCC itself provides the option ' -mxl-compat/-mno-xl-compat' [1]) (was '-mxl-call/-mno-xl-call in older GCC versions prior to 3.4 [2]) which state: ... Produce code that conforms more closely to IBM XL compiler semantics when using AIX-compatible ABI. *Pass floating-point arguments to prototyped functions beyond the register save area (RSA) on the stack in addition to argument FPRs*. Do not assume that most significant double in 128-bit long double value is properly rounded when comparing values and converting to double. Use XL symbol names for long double support routines. *The AIX calling convention was extended but not initially documented to handle an obscure K&R C case of calling a function that takes the address of its arguments with fewer arguments than declared. IBM XL compilers access floating point arguments which do not fit in the RSA from the stack when a subroutine is compiled without optimization*. Because always storing floating-point arguments on the stack is inefficient and rarely needed, this option is not enabled by default and only is necessary when calling subroutines compiled by IBM XL compilers without optimization. ... I think that's basically the reason why we've adapted the calling conventions as well in order to be on the safe side:) Regards, Volker [1] http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/RS_002f6000-and-PowerPC-Options.html [2] http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/RS_002f6000-and-PowerPC-Options.html On Mon, Sep 9, 2013 at 9:26 PM, Chris Plummer wrote: > Hi Goetz, > > From what I've read of both 32-bit and 64-bit PPC calling conventions, > arguments passed in registers are not also placed on the stack. > > > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#PARAM-PASS > > Can you please explain when you think an FP argument can end up both in a > register and on the stack? Is there some supporting documentation for this? > > thanks, > > Chris > > > On 9/9/13 2:41 AM, Lindenmaier, Goetz wrote: > > Hi,**** > > ** ** > > On PPC, the first 13 floating point arguments are passed in**** > > floating point registers. Also, all but the first 8 arguments**** > > are passed on the stack. So there can be floating point**** > > arguments that are passed on the stack and in a register.**** > > ** ** > > This change adapts the c_calling_conventions() to this.**** > > We duplicate the regs datastructure passed to c_calling_convention().**** > > This change adapts all the signatures of this function, which is **** > > defined in a shared file, but implemented platform dependent.**** > > How we use this can be seen in the ppc64 sharedRuntime file in **** > > function c_calling_convention() and the stub generators.**** > > > http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp > **** > > ** ** > > Please review and test this change.**** > > http://cr.openjdk.java.net/~goetz/webrevs/8024344-stackArg/**** > > ** ** > > Best regards,**** > > Goetz.**** > > ** ** > > ** ** > > ** ** > > > From jon.masamitsu at oracle.com Tue Sep 10 09:38:41 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 10 Sep 2013 09:38:41 -0700 Subject: RFR: 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 In-Reply-To: <522F1C72.1080906@oracle.com> References: <522F1C72.1080906@oracle.com> Message-ID: <522F4B11.2020807@oracle.com> Change looks good. Jon On 9/10/13 6:19 AM, Stefan Johansson wrote: > Hi all, > > Please review this really small fix for a test failure on Mac. > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8024176/webrev.00/ > > Summary: > A GC jtreg test fails on Mac, and when looking at the failure one can > see that the SA fails to find the type for an oop. It turns out the > code for reading compressed klass pointers in the sa-agent on Mac used > readCompOopAddress instead of readCompKlassAddress, this is wrong but > has been hidden since compressed oops and compressed klasses has used > the same base address. This was recently changed and now the SA agent > will show this issue when attached to a JVM using compressed klasses. > > The patch: > > --- > old/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java > 2013-09-10 13:52:17.163078372 +0200 > +++ > new/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java > 2013-09-10 13:52:17.079078971 +0200 > @@ -81,7 +81,7 @@ > > public Address getCompKlassAddressAt(long offset) > throws UnalignedAddressException, UnmappedAddressException { > - return debugger.readCompOopAddress(addr + offset); > + return debugger.readCompKlassAddress(addr + offset); > } > > // > > > Thanks, > Stefan From coleen.phillimore at oracle.com Tue Sep 10 10:27:56 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Tue, 10 Sep 2013 13:27:56 -0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522F1130.8050900@oracle.com> References: <522DAFF5.3030905@oracle.com> <522F1130.8050900@oracle.com> Message-ID: <522F569C.7050208@oracle.com> I have to admit, I was not looking forward to having multiple of these hotspot.log turds all over my file systems. I like Bengt's suggestion, below. Can we decline to make this change? Coleen On 9/10/2013 8:31 AM, Bengt Rutisson wrote: > On 9/10/13 1:31 PM, Staffan Larsen wrote: >> I'm not sure this change is only to the better. Since every run of a >> debug-build of hotspot creates this file, there is now going to be an >> enormous amount of these files create. At least for me that is going >> to be a big nuisance since they will clutter up every directory where >> I run hotspot. Would it be possible to keep hotspot.log as the >> default name, and have a flag which multiprocess tests can use to >> include the pid in the name? > > I agree with Staffan. This seems to be a quite invasive change in the > sense that it will create lots of files in our test and development > environments. > > In fact, isn't it possible for the multiprocess tests that have issues > to just specify the LogFile as: > > -XX:LogFile=hotspot_pid%p.log > > That wouldn't require any changes to the VM at all. > > Thanks, > Bengt > >> >> /Staffan >> >> On 9 sep 2013, at 14:24, Vladimir Ivanov >> wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>> 7 lines changed: 4 ins; 0 del; 3 mod >>> >>> Added pid of the Java process to default name of VM log file: >>> - old: hotspot.log >>> - new: hotspot_pid{pid}.log >>> >>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov > From david.holmes at oracle.com Tue Sep 10 17:47:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 10:47:03 +1000 Subject: RFR: 8024256 Minimal VM build is broken with PCH disabled In-Reply-To: <52299722.5000404@oracle.com> References: <52299722.5000404@oracle.com> Message-ID: <522FBD87.1080903@oracle.com> Still need a second reviewer on this please. Minimal VM folk in particular ;-) Thanks, David On 6/09/2013 6:49 PM, David Holmes wrote: > Disabling precompiled headers (PCH) has exposed a number of bugs with > the INCLUDE_XXX guards used by the minimal VM. In most cases a header > needed to be moved out of the guard or the guards removed. In one case a > file can be excluded completely and so its header no longer needs the > guard. > > webrev: http://cr.openjdk.java.net/~dholmes/8024256/webrev/ > > Thanks, > David From christian.thalinger at oracle.com Tue Sep 10 17:56:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Sep 2013 17:56:46 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds Message-ID: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> http://cr.openjdk.java.net/~twisti/8024545/webrev/ 8024545: make develop and notproduct flag values available in product builds Reviewed-by: Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. Before: $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 Attaching to process 9399, please wait... hsdb> flags -nd InitialHeapSize = 495006528 5 MaxHeapSize = 7920943104 5 UseCompressedKlassPointers = true 5 UseCompressedOops = true 5 UseParallelGC = true 5 hsdb> flags InlineMathNatives Couldn't find flag: InlineMathNatives After: $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 Attaching to process 3726, please wait... hsdb> flags -nd InitialHeapSize = 495006528 5 MaxHeapSize = 7920943104 5 UseCompressedKlassPointers = true 5 UseCompressedOops = true 5 UseParallelGC = true 5 hsdb> flags InlineMathNatives InlineMathNatives = true 0 This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} The output for product builds is unchanged. From christian.thalinger at oracle.com Tue Sep 10 18:00:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Sep 2013 18:00:09 -0700 Subject: RFR: 8024256 Minimal VM build is broken with PCH disabled In-Reply-To: <522FBD87.1080903@oracle.com> References: <52299722.5000404@oracle.com> <522FBD87.1080903@oracle.com> Message-ID: <10C0DF95-87E9-4A87-AA7F-D7307BEE4AB1@oracle.com> Looks good. -- Chris On Sep 10, 2013, at 5:47 PM, David Holmes wrote: > Still need a second reviewer on this please. > > Minimal VM folk in particular ;-) > > Thanks, > David > > On 6/09/2013 6:49 PM, David Holmes wrote: >> Disabling precompiled headers (PCH) has exposed a number of bugs with >> the INCLUDE_XXX guards used by the minimal VM. In most cases a header >> needed to be moved out of the guard or the guards removed. In one case a >> file can be excluded completely and so its header no longer needs the >> guard. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8024256/webrev/ >> >> Thanks, >> David From david.holmes at oracle.com Tue Sep 10 21:47:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 14:47:34 +1000 Subject: RFR: 8024505 [TESTBUG] update test groups for additional tests that can't run on the minimal VM Message-ID: <522FF5E6.7030407@oracle.com> The initial definition of the groups that need a full VM missed some of the tests that exec a second VM without passing on the VM selection flag. i.e we run jtreg with -vmoption:-minimal but the test then runs "java -XX:.. ,args>" and relies on jvm.cfg to select the default VM - which will not be the minimal VM unless in a JRE where only the minimal VM is present. Hence the test incorrectly passes. webrev: http://cr.openjdk.java.net/~dholmes/8024505/webrev/ I also fixed XCheckJSig as it can only run on a full JDK. Pushing through hotspot-emb. Thanks, David From stefan.johansson at oracle.com Tue Sep 10 23:50:06 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 11 Sep 2013 08:50:06 +0200 Subject: RFR: 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 In-Reply-To: <522F4B11.2020807@oracle.com> References: <522F1C72.1080906@oracle.com> <522F4B11.2020807@oracle.com> Message-ID: <5230129E.2080609@oracle.com> Thanks Staffan and Jon for reviewing this. Cheers, Stefan On 2013-09-10 18:38, Jon Masamitsu wrote: > Change looks good. > > Jon > > On 9/10/13 6:19 AM, Stefan Johansson wrote: >> Hi all, >> >> Please review this really small fix for a test failure on Mac. >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8024176/webrev.00/ >> >> Summary: >> A GC jtreg test fails on Mac, and when looking at the failure one can >> see that the SA fails to find the type for an oop. It turns out the >> code for reading compressed klass pointers in the sa-agent on Mac >> used readCompOopAddress instead of readCompKlassAddress, this is >> wrong but has been hidden since compressed oops and compressed >> klasses has used the same base address. This was recently changed and >> now the SA agent will show this issue when attached to a JVM using >> compressed klasses. >> >> The patch: >> >> --- >> old/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java >> 2013-09-10 13:52:17.163078372 +0200 >> +++ >> new/agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java >> 2013-09-10 13:52:17.079078971 +0200 >> @@ -81,7 +81,7 @@ >> >> public Address getCompKlassAddressAt(long offset) >> throws UnalignedAddressException, >> UnmappedAddressException { >> - return debugger.readCompOopAddress(addr + offset); >> + return debugger.readCompKlassAddress(addr + offset); >> } >> >> // >> >> >> Thanks, >> Stefan > From david.holmes at oracle.com Wed Sep 11 04:06:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 21:06:29 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock Message-ID: <52304EB5.7000603@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/6900441/webrev/ Short version: use CLOCK_MONOTONIC with pthread_cond_t objects for relative timed-waits. Long version - see below :) Thanks, David ----- Background: relative timed-waits (Thread.sleep, Object.wait, LockSupport.parkNanos) should not be affected by changes to the time-of-day clock. The linux implementation uses pthread_cond_timedwait on default initialized pthread_cond_t objects. pthread_cond_timedwait actually takes an absolute time and the default clock is CLOCK_REALTIME (which is a time-of-day clock). You would expect then that changing the time-of-day would impact these supposedly relative timed waits: time going forward would cause early returns; time going backwards would cause extended delays. But for many years it did not - the reason being that the glibc/pthreads implementors had not implemented it to work that way. Originally the monotonic clock didn't even exist so there was only one way this could be implemented (and we had LinuxThreads vs NPTL etc etc - lots of history). Skip forward to 2009 and glibc was modified to correct this behaviour - but only on 64-bit linux (no idea why - the 32-bit variant was added earlier this year but I don't know what glibc version that corresponds to). For 64-bit this was, as I understand it, glibc 2.12. By coincidence in 2009 I filed 6900441 as I knew we would have to change the implementation when glibc was fixed - unfortunately I wasn't aware that it actually had been fixed at that time. The bug was slated for future work, I went on to other things, blah blah blah ... We didn't get a flurry of bug reports in 2009, nor 2010, 2011 ... why not? Partly because people tend to avoid large jumps in system time and this bug only becomes noticeable when "large" backward jumps occur and threads 'hang'. (Forward jumps cause early returns that are either filtered out or permitted as spurious-wakeups). And partly it seems because it took time for glibc 2.12 to get into some Linux distributions and for people to take up the new version. Skip forward to today and we are starting to see a number of reports about this problem as people are now using the new glibc (and may have been for a while) and also seeing time changes have unexpected impact on their programs. So this needs to be fixed ASAP before it becomes a major problem and will be backported to OpenJDK 7 and 6. The fix is relatively straight-forward: the pthread_cond_t objects used for the relative timed-waits have to be associated with CLOCK_MONOTONIC so that they are not affected by changes to the time-of-day clock. There is a slight complication in that the LockSupport.park API supports both a relative and absolute timed-wait so we need two different pthread_cond_t each associated with different clocks. Notes: 1. This is a linux fix only. I don't know if we also have the problem on other OS but it hasn't been flagged and while I will check, it is more important to get this out for Linux ASAP. 2. Given the late stage of JDK 8 release cycle (to minimize risk), and to ease backporting to 6 and 7, I made no attempt to do any kind of code clean up here. This code is full of historical anachronisms and for Java 9 I hope to see it all cleaned up, but for now all the baggage and duplication must remain as-is. 3. We can obviously only fix this if we have a monotonic clock hence that has to be used to guard the new code. These days it would be extremely rare to not have the monotonic clock but I still use the guard. 4. CLOCK_MONOTONIC is not in fact completely immune to changes in the time of day clock but it won't jump backwards. The new clock on the block is CLOCK_MONOTONIC_RAW which should always advance at a constant rate with no jumps. We have a RFE to start using CLOCK_MONOTONIC_RAW for System.nanoTime(), and we would use it for the pthread_cond_t too, but we can't use that until the JDK 8 build platform is updated to a linux version that actually has that clock at build time. That update is very near but not yet here so we stay with CLOCK_MONOTONIC. From coleen.phillimore at oracle.com Wed Sep 11 04:57:03 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 11 Sep 2013 07:57:03 -0400 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> Message-ID: <52305A8F.3010508@oracle.com> Hi, Have you done performance testing on this change? When develop flags are not defined they are defined "const" false which enables the C++ compiler to do better optimizations. I've seen code that counts on that. If you want the values to be materialized, why not change the develop flag definition to be extern const (or some such). Coleen On 9/10/2013 8:56 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8024545/webrev/ > > 8024545: make develop and notproduct flag values available in product builds > Reviewed-by: > > Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. > > This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. > > Before: > > $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 > Attaching to process 9399, please wait... > hsdb> flags -nd > InitialHeapSize = 495006528 5 > MaxHeapSize = 7920943104 5 > UseCompressedKlassPointers = true 5 > UseCompressedOops = true 5 > UseParallelGC = true 5 > hsdb> flags InlineMathNatives > Couldn't find flag: InlineMathNatives > > After: > > $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 > Attaching to process 3726, please wait... > hsdb> flags -nd > InitialHeapSize = 495006528 5 > MaxHeapSize = 7920943104 5 > UseCompressedKlassPointers = true 5 > UseCompressedOops = true 5 > UseParallelGC = true 5 > hsdb> flags InlineMathNatives > InlineMathNatives = true 0 > > This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: > > uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} > > The output for product builds is unchanged. From erik.helin at oracle.com Wed Sep 11 08:18:21 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 11 Sep 2013 17:18:21 +0200 Subject: RFR: 8023476: Metaspace capacity > reserved Message-ID: <20130911151821.GA3486@ehelin-thinkpad> Hi all, this change is a first step to clean up the usage of words and bytes in metaspace.cpp/hpp. The change includes: - Appending function names with the unit of the size they return. All functions in MetaspaceAux returning bytes are now ending in _bytes and functions returning words ends in _words. - Appending function that iterates over the ClassLoaderDataGraph with _slow. These functions have also been made private since they should only be used internally for verification purposes. - Removing the function Metaspace::waste_bytes which isn't used - Making sure MetaspaceAux::reserved_bytes actually returns bytes instead of words. Webrev: http://cr.openjdk.java.net/~ehelin/8023476/webrev.00/ Testing: - JPRT - hotspot/test/gc/metaspace Thanks, Erik From stefan.karlsson at oracle.com Wed Sep 11 08:41:48 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Sep 2013 17:41:48 +0200 Subject: RFR: 8023476: Metaspace capacity > reserved In-Reply-To: <20130911151821.GA3486@ehelin-thinkpad> References: <20130911151821.GA3486@ehelin-thinkpad> Message-ID: <52308F3C.6010607@oracle.com> On 09/11/2013 05:18 PM, Erik Helin wrote: > Hi all, > > this change is a first step to clean up the usage of words and bytes in > metaspace.cpp/hpp. The change includes: > - Appending function names with the unit of the size they return. All > functions in MetaspaceAux returning bytes are now ending in _bytes and > functions returning words ends in _words. > - Appending function that iterates over the ClassLoaderDataGraph with > _slow. These functions have also been made private since they should > only be used internally for verification purposes. > - Removing the function Metaspace::waste_bytes which isn't used > - Making sure MetaspaceAux::reserved_bytes actually returns bytes > instead of words. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8023476/webrev.00/ Looks good. StefanK > > Testing: > - JPRT > - hotspot/test/gc/metaspace > > Thanks, > Erik From goetz.lindenmaier at sap.com Wed Sep 11 08:40:17 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 11 Sep 2013 15:40:17 +0000 Subject: RFR(M): 8024344: PPC64 (part 112): C argument in register AND stack slot. In-Reply-To: <522F675B.3080602@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D019FA3@DEWDFEMB12A.global.corp.sap> <522E20F0.1000102@oracle.com> <522F675B.3080602@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D01B40F@DEWDFEMB12A.global.corp.sap> Hi Chris, we also did a small experiment, showing that the xlc compiler copies the values on the stack, see below. We have tests for these calls, but they don?t show errors if we remove copying to the stack. But that only proves that the compiler we use does not rely on these stack fields, other code could do so. Best regards, Goetz. See this small C-program calling a function with floats. Gcc moves the constants to the 13 floating point registers, xlC in addition copies f9-f13 to the stack. Thanks to Axel for this! extern "C" void foo(float, float, float, float, float, float, float, float, float, float, float, float, float, float); int main(){ foo(0.1, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.2, 1.3, 1.4); } gcc -m64 -O3 -S test.cpp .L.main: .LFB2: mflr 0 .LCFI0: lfs 1,.LC0 at toc(2) lfs 0,.LC12 at toc(2) std 0,16(1) .LCFI1: stdu 1,-160(1) .LCFI2: fmr 2,1 lfs 3,.LC1 at toc(2) lfs 4,.LC2 at toc(2) lfs 5,.LC3 at toc(2) lfs 6,.LC4 at toc(2) lfs 7,.LC5 at toc(2) lfs 8,.LC6 at toc(2) stfs 0,156(1) lfs 9,.LC7 at toc(2) lfs 10,.LC8 at toc(2) lfs 11,.LC9 at toc(2) lfs 12,.LC10 at toc(2) lfs 13,.LC11 at toc(2) bl foo xlC -q64 -S -O3 test.cpp .main: # 0x0000000000000000 (H.4.NO_SYMBOL) mfspr r0,LR ld r3,T.10.NO_SYMBOL(RTOC) stdu SP,-160(SP) lfs fp9,0(r3) lfs fp10,4(r3) std r0,176(SP) stfs fp9,112(SP) lfs fp11,8(r3) lfs fp12,12(r3) stfs fp10,120(SP) stfs fp11,128(SP) lfs fp13,16(r3) lfs fp0,20(r3) stfs fp12,136(SP) stfs fp13,144(SP) lfs fp1,24(r3) fmr fp2,fp1 lfs fp3,28(r3) lfs fp4,32(r3) lfs fp5,36(r3) lfs fp6,40(r3) lfs fp7,44(r3) stfs fp0,152(SP) lfs fp8,48(r3) bl .foo{PR} From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Dienstag, 10. September 2013 20:39 To: Volker Simonis Cc: Lindenmaier, Goetz; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8024344: PPC64 (part 112): C argument in register AND stack slot. Hi Volker, Thanks for the explanation. Seems like you may need it for AIX but not linux, but it's fine if you want it always in place. It won't impact any existing ports, except for the needed mods to the c_calling_conventions() prototype. thanks, Chris On 9/10/13 8:25 AM, Volker Simonis wrote: Hi Chris, I think it is hard to find a real authoritative documentation for this convention. But GCC itself provides the option ' -mxl-compat/-mno-xl-compat' [1]) (was '-mxl-call/-mno-xl-call in older GCC versions prior to 3.4 [2]) which state: ... Produce code that conforms more closely to IBM XL compiler semantics when using AIX-compatible ABI. Pass floating-point arguments to prototyped functions beyond the register save area (RSA) on the stack in addition to argument FPRs. Do not assume that most significant double in 128-bit long double value is properly rounded when comparing values and converting to double. Use XL symbol names for long double support routines. The AIX calling convention was extended but not initially documented to handle an obscure K&R C case of calling a function that takes the address of its arguments with fewer arguments than declared. IBM XL compilers access floating point arguments which do not fit in the RSA from the stack when a subroutine is compiled without optimization. Because always storing floating-point arguments on the stack is inefficient and rarely needed, this option is not enabled by default and only is necessary when calling subroutines compiled by IBM XL compilers without optimization. ... I think that's basically the reason why we've adapted the calling conventions as well in order to be on the safe side:) Regards, Volker [1] http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/RS_002f6000-and-PowerPC-Options.html [2] http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/RS_002f6000-and-PowerPC-Options.html On Mon, Sep 9, 2013 at 9:26 PM, Chris Plummer > wrote: Hi Goetz, From what I've read of both 32-bit and 64-bit PPC calling conventions, arguments passed in registers are not also placed on the stack. http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#PARAM-PASS Can you please explain when you think an FP argument can end up both in a register and on the stack? Is there some supporting documentation for this? thanks, Chris On 9/9/13 2:41 AM, Lindenmaier, Goetz wrote: Hi, On PPC, the first 13 floating point arguments are passed in floating point registers. Also, all but the first 8 arguments are passed on the stack. So there can be floating point arguments that are passed on the stack and in a register. This change adapts the c_calling_conventions() to this. We duplicate the regs datastructure passed to c_calling_convention(). This change adapts all the signatures of this function, which is defined in a shared file, but implemented platform dependent. How we use this can be seen in the ppc64 sharedRuntime file in function c_calling_convention() and the stub generators. http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp Please review and test this change. http://cr.openjdk.java.net/~goetz/webrevs/8024344-stackArg/ Best regards, Goetz. From stefan.karlsson at oracle.com Wed Sep 11 09:10:23 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Sep 2013 18:10:23 +0200 Subject: Review request: 8024638: Count and expose the amount of committed memory in the metaspaces Message-ID: <523095EF.3030803@oracle.com> http://cr.openjdk.java.net/~stefank/8024547/webrev.00/ This change adds code to track the committed memory in the metaspaces. This fix is a prerequisite for: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces The patch is built upon this change, which is also out for review: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-September/010766.html Changes in the patch: - Renamed VirtualSpaceList::_virtual_space_total to VirtualSpaceList::_reserved_words. - Introduced a VirtualSpaceList::_committed_words. - Added a new function VirtualSpace::actual_committed_size(), which reports the memory committed by the OS. The per-existing function VirtualSpace::committed_size() only reports the amount of memory asked for by calls to VirtualSpace::expand_by, which can be significantly less because of OS allocation granularities and large pages. - Added code to tracks when the VirtualSpaces in the VirtualSpaceNodes are created, deleted, and expanded. - Added unit tests. thanks, StefanK From harold.seigel at oracle.com Wed Sep 11 09:08:54 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 11 Sep 2013 12:08:54 -0400 Subject: RFR: 8023476: Metaspace capacity > reserved In-Reply-To: <52308F3C.6010607@oracle.com> References: <20130911151821.GA3486@ehelin-thinkpad> <52308F3C.6010607@oracle.com> Message-ID: <52309596.3060406@oracle.com> Hi Erik, Your changes look good. Harold On 9/11/2013 11:41 AM, Stefan Karlsson wrote: > On 09/11/2013 05:18 PM, Erik Helin wrote: >> Hi all, >> >> this change is a first step to clean up the usage of words and bytes in >> metaspace.cpp/hpp. The change includes: >> - Appending function names with the unit of the size they return. All >> functions in MetaspaceAux returning bytes are now ending in _bytes >> and >> functions returning words ends in _words. >> - Appending function that iterates over the ClassLoaderDataGraph with >> _slow. These functions have also been made private since they should >> only be used internally for verification purposes. >> - Removing the function Metaspace::waste_bytes which isn't used >> - Making sure MetaspaceAux::reserved_bytes actually returns bytes >> instead of words. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8023476/webrev.00/ > > Looks good. > > StefanK >> >> Testing: >> - JPRT >> - hotspot/test/gc/metaspace >> >> Thanks, >> Erik > From christian.thalinger at oracle.com Wed Sep 11 09:29:37 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Sep 2013 09:29:37 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <52305A8F.3010508@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52305A8F.3010508@oracle.com> Message-ID: <1F3F2E67-9797-41AA-BBAF-0364CAE09120@oracle.com> On Sep 11, 2013, at 4:57 AM, Coleen Phillmore wrote: > > Hi, > > Have you done performance testing on this change? When develop flags are not defined they are defined "const" false which enables the C++ compiler to do better optimizations. I've seen code that counts on that. > If you want the values to be materialized, why not change the develop flag definition to be extern const (or some such). develop and notproduct flags are still constants; I didn't change that. I've just put the const value in the flags table. -- Chris > > Coleen > > On 9/10/2013 8:56 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >> >> 8024545: make develop and notproduct flag values available in product builds >> Reviewed-by: >> >> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >> >> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >> >> Before: >> >> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >> Attaching to process 9399, please wait... >> hsdb> flags -nd >> InitialHeapSize = 495006528 5 >> MaxHeapSize = 7920943104 5 >> UseCompressedKlassPointers = true 5 >> UseCompressedOops = true 5 >> UseParallelGC = true 5 >> hsdb> flags InlineMathNatives >> Couldn't find flag: InlineMathNatives >> >> After: >> >> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >> Attaching to process 3726, please wait... >> hsdb> flags -nd >> InitialHeapSize = 495006528 5 >> MaxHeapSize = 7920943104 5 >> UseCompressedKlassPointers = true 5 >> UseCompressedOops = true 5 >> UseParallelGC = true 5 >> hsdb> flags InlineMathNatives >> InlineMathNatives = true 0 >> >> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >> >> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >> >> The output for product builds is unchanged. > From vladimir.kozlov at oracle.com Wed Sep 11 09:50:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Sep 2013 09:50:12 -0700 Subject: RFR(M): 8024344: PPC64 (part 112): C argument in register AND stack slot. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D01B40F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D019FA3@DEWDFEMB12A.global.corp.sap> <522E20F0.1000102@oracle.com> <522F675B.3080602@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01B40F@DEWDFEMB12A.global.corp.sap> Message-ID: <52309F44.1080009@oracle.com> It seems we have agreement on c_calling_convention() changes. We need to change our closed sources, I will prepare them and test. Thanks, Vladimir On 9/11/13 8:40 AM, Lindenmaier, Goetz wrote: > Hi Chris, > > we also did a small experiment, showing that the xlc compiler copies the > values on the stack, see below. We have tests for these calls, but they don?t > show errors if we remove copying to the stack. But that only proves that > the compiler we use does not rely on these stack fields, other code could > do so. > > Best regards, > Goetz. > > > See this small C-program calling a function with floats. Gcc moves the constants to > the 13 floating point registers, xlC in addition copies f9-f13 to the stack. > Thanks to Axel for this! > > extern "C" void foo(float, float, float, float, float, float, float, float, float, float, float, float, float, float); > > int main(){ > foo(0.1, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.2, 1.3, 1.4); > } > > gcc -m64 -O3 -S test.cpp > > .L.main: > .LFB2: > mflr 0 > .LCFI0: > lfs 1,.LC0 at toc(2) > lfs 0,.LC12 at toc(2) > std 0,16(1) > .LCFI1: > stdu 1,-160(1) > .LCFI2: > fmr 2,1 > lfs 3,.LC1 at toc(2) > lfs 4,.LC2 at toc(2) > lfs 5,.LC3 at toc(2) > lfs 6,.LC4 at toc(2) > lfs 7,.LC5 at toc(2) > lfs 8,.LC6 at toc(2) > stfs 0,156(1) > lfs 9,.LC7 at toc(2) > lfs 10,.LC8 at toc(2) > lfs 11,.LC9 at toc(2) > lfs 12,.LC10 at toc(2) > lfs 13,.LC11 at toc(2) > bl foo > > xlC -q64 -S -O3 test.cpp > > .main: # 0x0000000000000000 (H.4.NO_SYMBOL) > mfspr r0,LR > ld r3,T.10.NO_SYMBOL(RTOC) > stdu SP,-160(SP) > lfs fp9,0(r3) > lfs fp10,4(r3) > std r0,176(SP) > stfs fp9,112(SP) > lfs fp11,8(r3) > lfs fp12,12(r3) > stfs fp10,120(SP) > stfs fp11,128(SP) > lfs fp13,16(r3) > lfs fp0,20(r3) > stfs fp12,136(SP) > stfs fp13,144(SP) > lfs fp1,24(r3) > fmr fp2,fp1 > lfs fp3,28(r3) > lfs fp4,32(r3) > lfs fp5,36(r3) > lfs fp6,40(r3) > lfs fp7,44(r3) > stfs fp0,152(SP) > lfs fp8,48(r3) > bl .foo{PR} > > > > > From: Chris Plummer [mailto:chris.plummer at oracle.com] > Sent: Dienstag, 10. September 2013 20:39 > To: Volker Simonis > Cc: Lindenmaier, Goetz; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8024344: PPC64 (part 112): C argument in register AND stack slot. > > Hi Volker, > > Thanks for the explanation. Seems like you may need it for AIX but not linux, but it's fine if you want it always in place. It won't impact any existing ports, except for the needed mods to the c_calling_conventions() prototype. > > thanks, > > Chris > > On 9/10/13 8:25 AM, Volker Simonis wrote: > Hi Chris, > > I think it is hard to find a real authoritative documentation for this convention. But GCC itself provides the option ' -mxl-compat/-mno-xl-compat' [1]) (was '-mxl-call/-mno-xl-call in older GCC versions prior to 3.4 [2]) which state: > > ... > Produce code that conforms more closely to IBM XL compiler semantics when using AIX-compatible ABI. Pass floating-point arguments to prototyped functions beyond the register save area (RSA) on the stack in addition to argument FPRs. Do not assume that most significant double in 128-bit long double value is properly rounded when comparing values and converting to double. Use XL symbol names for long double support routines. > > The AIX calling convention was extended but not initially documented to handle an obscure K&R C case of calling a function that takes the address of its arguments with fewer arguments than declared. IBM XL compilers access floating point arguments which do not fit in the RSA from the stack when a subroutine is compiled without optimization. Because always storing floating-point arguments on the stack is inefficient and rarely needed, this option is not enabled by default and only is necessary when calling subroutines compiled by IBM XL compilers without optimization. > ... > I think that's basically the reason why we've adapted the calling conventions as well in order to be on the safe side:) > Regards, > Volker > > [1] http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/RS_002f6000-and-PowerPC-Options.html > [2] http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/RS_002f6000-and-PowerPC-Options.html > > On Mon, Sep 9, 2013 at 9:26 PM, Chris Plummer > wrote: > Hi Goetz, > > From what I've read of both 32-bit and 64-bit PPC calling conventions, arguments passed in registers are not also placed on the stack. > > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#PARAM-PASS > > Can you please explain when you think an FP argument can end up both in a register and on the stack? Is there some supporting documentation for this? > > thanks, > > Chris > > > On 9/9/13 2:41 AM, Lindenmaier, Goetz wrote: > Hi, > > On PPC, the first 13 floating point arguments are passed in > floating point registers. Also, all but the first 8 arguments > are passed on the stack. So there can be floating point > arguments that are passed on the stack and in a register. > > This change adapts the c_calling_conventions() to this. > We duplicate the regs datastructure passed to c_calling_convention(). > This change adapts all the signatures of this function, which is > defined in a shared file, but implemented platform dependent. > How we use this can be seen in the ppc64 sharedRuntime file in > function c_calling_convention() and the stub generators. > http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp > > Please review and test this change. > http://cr.openjdk.java.net/~goetz/webrevs/8024344-stackArg/ > > Best regards, > Goetz. > > > > > > From christian.thalinger at oracle.com Wed Sep 11 09:55:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Sep 2013 09:55:20 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> Message-ID: <9BB345EC-A52B-4AA5-9C8F-6856F7A7B877@oracle.com> On Sep 10, 2013, at 5:56 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8024545/webrev/ > > 8024545: make develop and notproduct flag values available in product builds > Reviewed-by: > > Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. > > This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. Btw. I missed the perhaps most important data point: a linux_i486_minimal1 product build is increased by 22k. If that's too much we could disable this feature for minimal builds. -- Chris > > Before: > > $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 > Attaching to process 9399, please wait... > hsdb> flags -nd > InitialHeapSize = 495006528 5 > MaxHeapSize = 7920943104 5 > UseCompressedKlassPointers = true 5 > UseCompressedOops = true 5 > UseParallelGC = true 5 > hsdb> flags InlineMathNatives > Couldn't find flag: InlineMathNatives > > After: > > $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 > Attaching to process 3726, please wait... > hsdb> flags -nd > InitialHeapSize = 495006528 5 > MaxHeapSize = 7920943104 5 > UseCompressedKlassPointers = true 5 > UseCompressedOops = true 5 > UseParallelGC = true 5 > hsdb> flags InlineMathNatives > InlineMathNatives = true 0 > > This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: > > uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} > > The output for product builds is unchanged. From vladimir.x.ivanov at oracle.com Wed Sep 11 10:07:23 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 11 Sep 2013 21:07:23 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522F569C.7050208@oracle.com> References: <522DAFF5.3030905@oracle.com> <522F1130.8050900@oracle.com> <522F569C.7050208@oracle.com> Message-ID: <5230A34B.2020008@oracle.com> Coleen, I haven't integrated it yet. So, I'm open for discussion. Best regards, Vladimir Ivanov On 9/10/13 9:27 PM, Coleen Phillmore wrote: > > I have to admit, I was not looking forward to having multiple of these > hotspot.log turds all over my file systems. I like Bengt's suggestion, > below. Can we decline to make this change? > > Coleen > > On 9/10/2013 8:31 AM, Bengt Rutisson wrote: >> On 9/10/13 1:31 PM, Staffan Larsen wrote: >>> I'm not sure this change is only to the better. Since every run of a >>> debug-build of hotspot creates this file, there is now going to be an >>> enormous amount of these files create. At least for me that is going >>> to be a big nuisance since they will clutter up every directory where >>> I run hotspot. Would it be possible to keep hotspot.log as the >>> default name, and have a flag which multiprocess tests can use to >>> include the pid in the name? >> >> I agree with Staffan. This seems to be a quite invasive change in the >> sense that it will create lots of files in our test and development >> environments. >> >> In fact, isn't it possible for the multiprocess tests that have issues >> to just specify the LogFile as: >> >> -XX:LogFile=hotspot_pid%p.log >> >> That wouldn't require any changes to the VM at all. >> >> Thanks, >> Bengt >> >>> >>> /Staffan >>> >>> On 9 sep 2013, at 14:24, Vladimir Ivanov >>> wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>> >>>> Added pid of the Java process to default name of VM log file: >>>> - old: hotspot.log >>>> - new: hotspot_pid{pid}.log >>>> >>>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>>> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >> > From harold.seigel at oracle.com Wed Sep 11 12:09:14 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 11 Sep 2013 15:09:14 -0400 Subject: RFR: 8024505 [TESTBUG] update test groups for additional tests that can't run on the minimal VM In-Reply-To: <522FF5E6.7030407@oracle.com> References: <522FF5E6.7030407@oracle.com> Message-ID: <5230BFDA.9030502@oracle.com> Hi David, Your changes look good. Harold On 9/11/2013 12:47 AM, David Holmes wrote: > The initial definition of the groups that need a full VM missed some of > the tests that exec a second VM without passing on the VM selection > flag. i.e we run jtreg with -vmoption:-minimal but the test then runs > "java -XX:.. ,args>" and relies on jvm.cfg to select the default VM - > which will not be the minimal VM unless in a JRE where only the minimal > VM is present. Hence the test incorrectly passes. > > webrev: > > http://cr.openjdk.java.net/~dholmes/8024505/webrev/ > > I also fixed XCheckJSig as it can only run on a full JDK. > > Pushing through hotspot-emb. > > Thanks, > David From joseph.provino at oracle.com Wed Sep 11 13:22:27 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 11 Sep 2013 16:22:27 -0400 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <9BB345EC-A52B-4AA5-9C8F-6856F7A7B877@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <9BB345EC-A52B-4AA5-9C8F-6856F7A7B877@oracle.com> Message-ID: <5230D103.5010006@oracle.com> On 9/11/2013 12:55 PM, Christian Thalinger wrote: > On Sep 10, 2013, at 5:56 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >> >> 8024545: make develop and notproduct flag values available in product builds >> Reviewed-by: >> >> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >> >> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. > Btw. I missed the perhaps most important data point: a linux_i486_minimal1 product build is increased by 22k. > > If that's too much we could disable this feature for minimal builds. A 22k increase still keeps the minimal VM under 3.5M which is what we requested in a CCC. However, there are features excluded from the minimal VM such as SA so it doesn't make sense to allow those options. joe > > -- Chris > >> Before: >> >> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >> Attaching to process 9399, please wait... >> hsdb> flags -nd >> InitialHeapSize = 495006528 5 >> MaxHeapSize = 7920943104 5 >> UseCompressedKlassPointers = true 5 >> UseCompressedOops = true 5 >> UseParallelGC = true 5 >> hsdb> flags InlineMathNatives >> Couldn't find flag: InlineMathNatives >> >> After: >> >> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >> Attaching to process 3726, please wait... >> hsdb> flags -nd >> InitialHeapSize = 495006528 5 >> MaxHeapSize = 7920943104 5 >> UseCompressedKlassPointers = true 5 >> UseCompressedOops = true 5 >> UseParallelGC = true 5 >> hsdb> flags InlineMathNatives >> InlineMathNatives = true 0 >> >> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >> >> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >> >> The output for product builds is unchanged. From stefan.karlsson at oracle.com Wed Sep 11 14:03:58 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Sep 2013 23:03:58 +0200 Subject: Review request: 8024638: Count and expose the amount of committed memory in the metaspaces In-Reply-To: <523095EF.3030803@oracle.com> References: <523095EF.3030803@oracle.com> Message-ID: <5230DABE.10403@oracle.com> http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ Further testing showed that one of the asserts in actual_committed_size was incorrect when the the middle region of the VirtualSpace was empty and the middle alignment was larger than the other alignments. This can happen when large pages are used and the size of the VirtualSpace is within the range [large_page_size, 2 * large_page_size). I rewrote the asserts to handle that and similar cases. I also added new unit test cases that provoked this incorrect assert. Thanks Erik Helin for finding this (and also for helping out with the original patch). thanks, StefanK On 9/11/13 6:10 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024547/webrev.00/ > > This change adds code to track the committed memory in the metaspaces. > > This fix is a prerequisite for: > 8024547: MaxMetaspaceSize should limit the committed memory used by > the metaspaces > > The patch is built upon this change, which is also out for review: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-September/010766.html > > > Changes in the patch: > > - Renamed VirtualSpaceList::_virtual_space_total to > VirtualSpaceList::_reserved_words. > > - Introduced a VirtualSpaceList::_committed_words. > > - Added a new function VirtualSpace::actual_committed_size(), which > reports the memory committed by the OS. The per-existing function > VirtualSpace::committed_size() only reports the amount of memory asked > for by calls to VirtualSpace::expand_by, which can be significantly > less because of OS allocation granularities and large pages. > > - Added code to tracks when the VirtualSpaces in the VirtualSpaceNodes > are created, deleted, and expanded. > > - Added unit tests. > > thanks, > StefanK From daniel.daugherty at oracle.com Wed Sep 11 14:10:05 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 11 Sep 2013 15:10:05 -0600 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <52304EB5.7000603@oracle.com> References: <52304EB5.7000603@oracle.com> Message-ID: <5230DC2D.1020204@oracle.com> On 9/11/13 5:06 AM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev/ Looks like Ron attached the two TimeJump... tests that were developed back in July. Please let Ron, Jerry and I know how these tests work with your fix in place. (We're curious...) Short version: Thumbs up! Nothing critical to change Long version: src/os/linux/vm/os_linux.hpp No comments. src/os/linux/vm/os_linux.cpp line 4712: warning("Unable to associate monotonic clock with ... is way too long and should be split into at least two strings. line 4713: } line 4714 : else { HotSpot style is "} else {" (i.e., on the same line) line 4715: fatal(err_msg("pthread_condattr_setclock: %s", strerror(status))); line is indented two spaces too many line 5541: assert_status(status == 0, status, "clock_gettime"); line 5553: assert(status == 0, "gettimeofday"); So why is one an assert_status() call and the other is a plain old assert() call? line 5808: // tty->print_cr("abstime = (%lld, %lld)", (jlong)absTime->tv_sec, (jlong)absTime->tv_nsec); Leftover debugging/testing code? Dan > Short version: use CLOCK_MONOTONIC with pthread_cond_t objects for > relative timed-waits. > > Long version - see below :) > > Thanks, > David > ----- > > Background: relative timed-waits (Thread.sleep, Object.wait, > LockSupport.parkNanos) should not be affected by changes to the > time-of-day clock. The linux implementation uses > pthread_cond_timedwait on default initialized pthread_cond_t objects. > pthread_cond_timedwait actually takes an absolute time and the default > clock is CLOCK_REALTIME (which is a time-of-day clock). You would > expect then that changing the time-of-day would impact these > supposedly relative timed waits: time going forward would cause early > returns; time going backwards would cause extended delays. But for > many years it did not - the reason being that the glibc/pthreads > implementors had not implemented it to work that way. Originally the > monotonic clock didn't even exist so there was only one way this could > be implemented (and we had LinuxThreads vs NPTL etc etc - lots of > history). > > Skip forward to 2009 and glibc was modified to correct this behaviour > - but only on 64-bit linux (no idea why - the 32-bit variant was added > earlier this year but I don't know what glibc version that corresponds > to). For 64-bit this was, as I understand it, glibc 2.12. By > coincidence in 2009 I filed 6900441 as I knew we would have to change > the implementation when glibc was fixed - unfortunately I wasn't aware > that it actually had been fixed at that time. The bug was slated for > future work, I went on to other things, blah blah blah ... > > We didn't get a flurry of bug reports in 2009, nor 2010, 2011 ... why > not? Partly because people tend to avoid large jumps in system time > and this bug only becomes noticeable when "large" backward jumps occur > and threads 'hang'. (Forward jumps cause early returns that are either > filtered out or permitted as spurious-wakeups). And partly it seems > because it took time for glibc 2.12 to get into some Linux > distributions and for people to take up the new version. > > Skip forward to today and we are starting to see a number of reports > about this problem as people are now using the new glibc (and may have > been for a while) and also seeing time changes have unexpected impact > on their programs. So this needs to be fixed ASAP before it becomes a > major problem and will be backported to OpenJDK 7 and 6. > > The fix is relatively straight-forward: the pthread_cond_t objects > used for the relative timed-waits have to be associated with > CLOCK_MONOTONIC so that they are not affected by changes to the > time-of-day clock. There is a slight complication in that the > LockSupport.park API supports both a relative and absolute timed-wait > so we need two different pthread_cond_t each associated with different > clocks. > > Notes: > > 1. This is a linux fix only. I don't know if we also have the problem > on other OS but it hasn't been flagged and while I will check, it is > more important to get this out for Linux ASAP. > > 2. Given the late stage of JDK 8 release cycle (to minimize risk), and > to ease backporting to 6 and 7, I made no attempt to do any kind of > code clean up here. This code is full of historical anachronisms and > for Java 9 I hope to see it all cleaned up, but for now all the > baggage and duplication must remain as-is. > > 3. We can obviously only fix this if we have a monotonic clock hence > that has to be used to guard the new code. These days it would be > extremely rare to not have the monotonic clock but I still use the guard. > > 4. CLOCK_MONOTONIC is not in fact completely immune to changes in the > time of day clock but it won't jump backwards. The new clock on the > block is CLOCK_MONOTONIC_RAW which should always advance at a constant > rate with no jumps. We have a RFE to start using CLOCK_MONOTONIC_RAW > for System.nanoTime(), and we would use it for the pthread_cond_t too, > but we can't use that until the JDK 8 build platform is updated to a > linux version that actually has that clock at build time. That update > is very near but not yet here so we stay with CLOCK_MONOTONIC. From christian.thalinger at oracle.com Wed Sep 11 14:30:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Sep 2013 14:30:20 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5230D103.5010006@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <9BB345EC-A52B-4AA5-9C8F-6856F7A7B877@oracle.com> <5230D103.5010006@oracle.com> Message-ID: <8E389396-4B6C-428D-A1F9-5413F3E707A9@oracle.com> On Sep 11, 2013, at 1:22 PM, Joseph Provino wrote: > > On 9/11/2013 12:55 PM, Christian Thalinger wrote: >> On Sep 10, 2013, at 5:56 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>> >>> 8024545: make develop and notproduct flag values available in product builds >>> Reviewed-by: >>> >>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>> >>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >> Btw. I missed the perhaps most important data point: a linux_i486_minimal1 product build is increased by 22k. >> >> If that's too much we could disable this feature for minimal builds. > > A 22k increase still keeps the minimal VM under 3.5M which is what we requested in a CCC. > > However, there are features excluded from the minimal VM such as SA so it doesn't make > sense to allow those options. Right. I saw that minimal also doesn't build vmStructs. Question: could the additional information be useful in GDB debugging? -- Chris > > joe > >> >> -- Chris >> >>> Before: >>> >>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>> Attaching to process 9399, please wait... >>> hsdb> flags -nd >>> InitialHeapSize = 495006528 5 >>> MaxHeapSize = 7920943104 5 >>> UseCompressedKlassPointers = true 5 >>> UseCompressedOops = true 5 >>> UseParallelGC = true 5 >>> hsdb> flags InlineMathNatives >>> Couldn't find flag: InlineMathNatives >>> >>> After: >>> >>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>> Attaching to process 3726, please wait... >>> hsdb> flags -nd >>> InitialHeapSize = 495006528 5 >>> MaxHeapSize = 7920943104 5 >>> UseCompressedKlassPointers = true 5 >>> UseCompressedOops = true 5 >>> UseParallelGC = true 5 >>> hsdb> flags InlineMathNatives >>> InlineMathNatives = true 0 >>> >>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>> >>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>> >>> The output for product builds is unchanged. > From serguei.spitsyn at oracle.com Wed Sep 11 14:39:32 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 11 Sep 2013 14:39:32 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed Message-ID: <5230E314.4010508@oracle.com> Please, review the fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 Summary: Handle pending exceptions instead of firing a guarantee() in the JVMTI rewrite_cp_refs_in_method(). Testing: UTE tests - in progress: vm.quick-pcl.testlist with limited Metaspace memory, nsk.jvmti.testlist, nsk.jdi.testlist, Jtreg java/lang/instrument Thanks, Serguei From joseph.provino at oracle.com Wed Sep 11 14:40:18 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 11 Sep 2013 17:40:18 -0400 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <8E389396-4B6C-428D-A1F9-5413F3E707A9@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <9BB345EC-A52B-4AA5-9C8F-6856F7A7B877@oracle.com> <5230D103.5010006@oracle.com> <8E389396-4B6C-428D-A1F9-5413F3E707A9@oracle.com> Message-ID: <5230E342.7000903@oracle.com> On 9/11/2013 5:30 PM, Christian Thalinger wrote: > On Sep 11, 2013, at 1:22 PM, Joseph Provino wrote: > >> On 9/11/2013 12:55 PM, Christian Thalinger wrote: >>> On Sep 10, 2013, at 5:56 PM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>> >>>> 8024545: make develop and notproduct flag values available in product builds >>>> Reviewed-by: >>>> >>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>> >>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>> Btw. I missed the perhaps most important data point: a linux_i486_minimal1 product build is increased by 22k. >>> >>> If that's too much we could disable this feature for minimal builds. >> A 22k increase still keeps the minimal VM under 3.5M which is what we requested in a CCC. >> >> However, there are features excluded from the minimal VM such as SA so it doesn't make >> sense to allow those options. > Right. I saw that minimal also doesn't build vmStructs. > > Question: could the additional information be useful in GDB debugging? Hi Chris, I'm not sure what you mean. I was thinking of options you don't want to allow because they won't do anything in the minimal vm. joe > > -- Chris > >> joe >> >>> -- Chris >>> >>>> Before: >>>> >>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>> Attaching to process 9399, please wait... >>>> hsdb> flags -nd >>>> InitialHeapSize = 495006528 5 >>>> MaxHeapSize = 7920943104 5 >>>> UseCompressedKlassPointers = true 5 >>>> UseCompressedOops = true 5 >>>> UseParallelGC = true 5 >>>> hsdb> flags InlineMathNatives >>>> Couldn't find flag: InlineMathNatives >>>> >>>> After: >>>> >>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>> Attaching to process 3726, please wait... >>>> hsdb> flags -nd >>>> InitialHeapSize = 495006528 5 >>>> MaxHeapSize = 7920943104 5 >>>> UseCompressedKlassPointers = true 5 >>>> UseCompressedOops = true 5 >>>> UseParallelGC = true 5 >>>> hsdb> flags InlineMathNatives >>>> InlineMathNatives = true 0 >>>> >>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>> >>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>> >>>> The output for product builds is unchanged. From serguei.spitsyn at oracle.com Wed Sep 11 15:02:59 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 11 Sep 2013 15:02:59 -0700 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool Message-ID: <5230E893.8040603@oracle.com> Please, review the fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly. Testing: UTE tests - in progress: vm.quick-pcl.testlist with limited Metaspace memory, nsk.jvmti.testlist, nsk.jdi.testlist, Jtreg java/lang/instrument Thanks, Serguei From serguei.spitsyn at oracle.com Wed Sep 11 15:13:15 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 11 Sep 2013 15:13:15 -0700 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated Message-ID: <5230EAFB.5040908@oracle.com> Please, review the fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite. Testing: UTE tests - in progress: vm.quick-pcl.testlist with limited Metaspace memory, nsk.jvmti.testlist, nsk.jdi.testlist, Jtreg java/lang/instrument Thanks, Serguei From david.holmes at oracle.com Wed Sep 11 16:14:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 09:14:50 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5230DC2D.1020204@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> Message-ID: <5230F96A.30306@oracle.com> updated webrev: http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: > On 9/11/13 5:06 AM, David Holmes wrote: >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/6900441/webrev/ > > Looks like Ron attached the two TimeJump... tests that were developed > back in July. Please let Ron, Jerry and I know how these tests work > with your fix in place. (We're curious...) Of course these tests pass (and many thanks to everyone involved in providing them) - I should have mentioned that. I also adapted them to test parkNanos so that we cover the three main user-level API's (there are only two VM-level APIs). I also adapted into a separate (manual observation) test of parkUntil to ensure that absolute waits do get affected by the clock change (this passes with old and new code of course). > Short version: Thumbs up! Nothing critical to change Thanks. > Long version: > > src/os/linux/vm/os_linux.hpp > No comments. > > src/os/linux/vm/os_linux.cpp > line 4712: warning("Unable to associate monotonic clock with ... > is way too long and should be split into at least two strings. Fixed. > line 4713: } > line 4714 : else { > HotSpot style is "} else {" (i.e., on the same line) Fixed. Along with a fix pre-existing ones in the same code. > line 4715: fatal(err_msg("pthread_condattr_setclock: %s", > strerror(status))); > line is indented two spaces too many Fixed. > line 5541: assert_status(status == 0, status, "clock_gettime"); > line 5553: assert(status == 0, "gettimeofday"); > So why is one an assert_status() call and the other is a > plain old assert() call? Different API's. The old unix API's, like gettimeofday return -1 on error and set errno. The "modern" posix APIs, eg pthread APIs and clock_gettime etc, return the actual error code on error - hence assert_status can be used to show the actual error in that case. > line 5808: // tty->print_cr("abstime = (%lld, %lld)", > (jlong)absTime->tv_sec, > (jlong)absTime->tv_nsec); > > Leftover debugging/testing code? Yep -fixed. Thanks again! David ----- > Dan > > > >> Short version: use CLOCK_MONOTONIC with pthread_cond_t objects for >> relative timed-waits. >> >> Long version - see below :) >> >> Thanks, >> David >> ----- >> >> Background: relative timed-waits (Thread.sleep, Object.wait, >> LockSupport.parkNanos) should not be affected by changes to the >> time-of-day clock. The linux implementation uses >> pthread_cond_timedwait on default initialized pthread_cond_t objects. >> pthread_cond_timedwait actually takes an absolute time and the default >> clock is CLOCK_REALTIME (which is a time-of-day clock). You would >> expect then that changing the time-of-day would impact these >> supposedly relative timed waits: time going forward would cause early >> returns; time going backwards would cause extended delays. But for >> many years it did not - the reason being that the glibc/pthreads >> implementors had not implemented it to work that way. Originally the >> monotonic clock didn't even exist so there was only one way this could >> be implemented (and we had LinuxThreads vs NPTL etc etc - lots of >> history). >> >> Skip forward to 2009 and glibc was modified to correct this behaviour >> - but only on 64-bit linux (no idea why - the 32-bit variant was added >> earlier this year but I don't know what glibc version that corresponds >> to). For 64-bit this was, as I understand it, glibc 2.12. By >> coincidence in 2009 I filed 6900441 as I knew we would have to change >> the implementation when glibc was fixed - unfortunately I wasn't aware >> that it actually had been fixed at that time. The bug was slated for >> future work, I went on to other things, blah blah blah ... >> >> We didn't get a flurry of bug reports in 2009, nor 2010, 2011 ... why >> not? Partly because people tend to avoid large jumps in system time >> and this bug only becomes noticeable when "large" backward jumps occur >> and threads 'hang'. (Forward jumps cause early returns that are either >> filtered out or permitted as spurious-wakeups). And partly it seems >> because it took time for glibc 2.12 to get into some Linux >> distributions and for people to take up the new version. >> >> Skip forward to today and we are starting to see a number of reports >> about this problem as people are now using the new glibc (and may have >> been for a while) and also seeing time changes have unexpected impact >> on their programs. So this needs to be fixed ASAP before it becomes a >> major problem and will be backported to OpenJDK 7 and 6. >> >> The fix is relatively straight-forward: the pthread_cond_t objects >> used for the relative timed-waits have to be associated with >> CLOCK_MONOTONIC so that they are not affected by changes to the >> time-of-day clock. There is a slight complication in that the >> LockSupport.park API supports both a relative and absolute timed-wait >> so we need two different pthread_cond_t each associated with different >> clocks. >> >> Notes: >> >> 1. This is a linux fix only. I don't know if we also have the problem >> on other OS but it hasn't been flagged and while I will check, it is >> more important to get this out for Linux ASAP. >> >> 2. Given the late stage of JDK 8 release cycle (to minimize risk), and >> to ease backporting to 6 and 7, I made no attempt to do any kind of >> code clean up here. This code is full of historical anachronisms and >> for Java 9 I hope to see it all cleaned up, but for now all the >> baggage and duplication must remain as-is. >> >> 3. We can obviously only fix this if we have a monotonic clock hence >> that has to be used to guard the new code. These days it would be >> extremely rare to not have the monotonic clock but I still use the guard. >> >> 4. CLOCK_MONOTONIC is not in fact completely immune to changes in the >> time of day clock but it won't jump backwards. The new clock on the >> block is CLOCK_MONOTONIC_RAW which should always advance at a constant >> rate with no jumps. We have a RFE to start using CLOCK_MONOTONIC_RAW >> for System.nanoTime(), and we would use it for the pthread_cond_t too, >> but we can't use that until the JDK 8 build platform is updated to a >> linux version that actually has that clock at build time. That update >> is very near but not yet here so we stay with CLOCK_MONOTONIC. > From christian.thalinger at oracle.com Wed Sep 11 16:29:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Sep 2013 16:29:45 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5230E342.7000903@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <9BB345EC-A52B-4AA5-9C8F-6856F7A7B877@oracle.com> <5230D103.5010006@oracle.com> <8E389396-4B6C-428D-A1F9-5413F3E707A9@oracle.com> <5230E342.7000903@oracle.com> Message-ID: On Sep 11, 2013, at 2:40 PM, Joseph Provino wrote: > > On 9/11/2013 5:30 PM, Christian Thalinger wrote: >> On Sep 11, 2013, at 1:22 PM, Joseph Provino wrote: >> >>> On 9/11/2013 12:55 PM, Christian Thalinger wrote: >>>> On Sep 10, 2013, at 5:56 PM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>> >>>>> 8024545: make develop and notproduct flag values available in product builds >>>>> Reviewed-by: >>>>> >>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>> >>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>> Btw. I missed the perhaps most important data point: a linux_i486_minimal1 product build is increased by 22k. >>>> >>>> If that's too much we could disable this feature for minimal builds. >>> A 22k increase still keeps the minimal VM under 3.5M which is what we requested in a CCC. >>> >>> However, there are features excluded from the minimal VM such as SA so it doesn't make >>> sense to allow those options. >> Right. I saw that minimal also doesn't build vmStructs. >> >> Question: could the additional information be useful in GDB debugging? > > Hi Chris, I'm not sure what you mean. I was thinking of options you don't want to allow > because they won't do anything in the minimal vm. Eh, let me explain again. The purpose of this change is to be able to read the values of all flags used in a binary; even develop and notproduct ones. This might be helpful to get the value for e.g. C1's InstructionCountCutoff flag without going back to the source code and dig it out. Especially helpful if it happens to be a value that changes over time between releases. But this is just a nice side effect. The actual motivation is to be able to use the same constant values as the VM's C++ code in a JIT compiler that is written in Java. One good example here is BciProfileWidth. Right now this is a develop flag and has the default value of 2. But this could change any time and we need to use the same value in Java as well. -- Chris > > joe > >> >> -- Chris >> >>> joe >>> >>>> -- Chris >>>> >>>>> Before: >>>>> >>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>> Attaching to process 9399, please wait... >>>>> hsdb> flags -nd >>>>> InitialHeapSize = 495006528 5 >>>>> MaxHeapSize = 7920943104 5 >>>>> UseCompressedKlassPointers = true 5 >>>>> UseCompressedOops = true 5 >>>>> UseParallelGC = true 5 >>>>> hsdb> flags InlineMathNatives >>>>> Couldn't find flag: InlineMathNatives >>>>> >>>>> After: >>>>> >>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>> Attaching to process 3726, please wait... >>>>> hsdb> flags -nd >>>>> InitialHeapSize = 495006528 5 >>>>> MaxHeapSize = 7920943104 5 >>>>> UseCompressedKlassPointers = true 5 >>>>> UseCompressedOops = true 5 >>>>> UseParallelGC = true 5 >>>>> hsdb> flags InlineMathNatives >>>>> InlineMathNatives = true 0 >>>>> >>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>> >>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>> >>>>> The output for product builds is unchanged. > From david.holmes at oracle.com Wed Sep 11 17:34:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 10:34:47 +1000 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> Message-ID: <52310C27.2060107@oracle.com> Hi Chris, There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: + if (is_constant_in_binary()) { + fatal(err_msg("flag is constant: %s", _name)); into a check_writable() method so that it isn't duplicated so much. I also wonder whether a ConstFlag sub/superclass would simplify this at all? That aside I'm curious why the minimal VM size change is only 22K when client is 32K? Thanks, David On 11/09/2013 10:56 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8024545/webrev/ > > 8024545: make develop and notproduct flag values available in product builds > Reviewed-by: > > Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. > > This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. > > Before: > > $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 > Attaching to process 9399, please wait... > hsdb> flags -nd > InitialHeapSize = 495006528 5 > MaxHeapSize = 7920943104 5 > UseCompressedKlassPointers = true 5 > UseCompressedOops = true 5 > UseParallelGC = true 5 > hsdb> flags InlineMathNatives > Couldn't find flag: InlineMathNatives > > After: > > $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 > Attaching to process 3726, please wait... > hsdb> flags -nd > InitialHeapSize = 495006528 5 > MaxHeapSize = 7920943104 5 > UseCompressedKlassPointers = true 5 > UseCompressedOops = true 5 > UseParallelGC = true 5 > hsdb> flags InlineMathNatives > InlineMathNatives = true 0 > > This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: > > uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} > > The output for product builds is unchanged. > From vladimir.kozlov at oracle.com Wed Sep 11 17:54:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Sep 2013 17:54:36 -0700 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> Message-ID: <523110CC.1040307@oracle.com> Goetz, Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp to sharedRuntime_ppc.cpp? They are static and not used in any other places. Why only intrinsify_fill changed? What about arraycopy and other stubs which use int parameter? loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also you can use (t == T_INT || is_subword_type(t)) check instead for int types. Thanks, Vladimir On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: > Hi, > > This is the first of about 10 changes taking us to a rudimentary c2 > compiler on ppc64. > > Some platforms, as ppc and s390x/zArch require that 32-bit ints are > passed as 64-bit values to C functions. This change adds support to > adapt the signature and to issue proper casts to c2-compiled stubs. The > functions are used in generate_native_wrapper(). We also need to adapt > the signature in PhaseIdealLoop::intrinsify_fill(). > > We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with > > enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing > > platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by > > ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp > > line 1752 ff. > > > > http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ > > Please review and test this change. > > Best regards, > > Goetz. > From david.holmes at oracle.com Wed Sep 11 20:54:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 13:54:07 +1000 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <5230E314.4010508@oracle.com> References: <5230E314.4010508@oracle.com> Message-ID: <52313ADF.2060505@oracle.com> Hi Dmitry, It seems odd that you install the new_method even if there was an exception. What if the new_method is not valid because of the exception ? Also once you've cleared the exception and returned false, the user has no information as to why this failed. I understand we don't want to hit the guarantee here, but it seems there is a hole in the error flow. David On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 > jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 > > Summary: > Handle pending exceptions instead of firing a guarantee() in the > JVMTI rewrite_cp_refs_in_method(). > > > Testing: > UTE tests - in progress: vm.quick-pcl.testlist with limited > Metaspace memory, > nsk.jvmti.testlist, > nsk.jdi.testlist, > Jtreg java/lang/instrument > > Thanks, > Serguei From david.holmes at oracle.com Wed Sep 11 20:58:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 13:58:31 +1000 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52313ADF.2060505@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> Message-ID: <52313BE7.7030704@oracle.com> On 12/09/2013 1:54 PM, David Holmes wrote: > Hi Dmitry, Sorry Serguei. David > It seems odd that you install the new_method even if there was an > exception. What if the new_method is not valid because of the exception ? > > Also once you've cleared the exception and returned false, the user has > no information as to why this failed. I understand we don't want to hit > the guarantee here, but it seems there is a hole in the error flow. > > David > > On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >> >> >> Summary: >> Handle pending exceptions instead of firing a guarantee() in the >> JVMTI rewrite_cp_refs_in_method(). >> >> >> Testing: >> UTE tests - in progress: vm.quick-pcl.testlist with limited >> Metaspace memory, >> nsk.jvmti.testlist, >> nsk.jdi.testlist, >> Jtreg java/lang/instrument >> >> Thanks, >> Serguei From david.holmes at oracle.com Wed Sep 11 21:04:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 14:04:04 +1000 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <5230E893.8040603@oracle.com> References: <5230E893.8040603@oracle.com> Message-ID: <52313D34.5090605@oracle.com> Hi Serguei, Typo: 2489 // scratch_cp is a merged constant po/ ol In VM_RedefineClasses::set_new_constant_pool do you not need to de-allocate smaller_cp if you return due to an exception here: 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1, CHECK); David ----- On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 > jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 > > > Summary: > The OOME's in the JVMTI merge_cp_and_rewrite and > set_new_constant_pool must be handled correctly. > > > Testing: > UTE tests - in progress: vm.quick-pcl.testlist with limited > Metaspace memory, > nsk.jvmti.testlist, > nsk.jdi.testlist, > Jtreg java/lang/instrument > > Thanks, > Serguei From david.holmes at oracle.com Wed Sep 11 21:09:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 14:09:07 +1000 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <5230EAFB.5040908@oracle.com> References: <5230EAFB.5040908@oracle.com> Message-ID: <52313E63.8010904@oracle.com> Hi Serguei, This is more consistent with the surrounding code, but: 1. Why no RC_TRACE_WITH_THREAD for this case? 2. If an exception is pending, that isn't OOME, shouldn't "res" already not be JVMTI_ERROR_NONE and so res should be returned in the non-OOME case? David On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 > jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 > > > Summary: > Pending exceptions must be handled properly after a call to the JVMTI > merge_cp_and_rewrite. > > > > Testing: > UTE tests - in progress: vm.quick-pcl.testlist with limited > Metaspace memory, > nsk.jvmti.testlist, > nsk.jdi.testlist, > Jtreg java/lang/instrument > > Thanks, > Serguei > From mikael.gerdin at oracle.com Thu Sep 12 00:26:44 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Sep 2013 09:26:44 +0200 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <52304EB5.7000603@oracle.com> References: <52304EB5.7000603@oracle.com> Message-ID: <52316CB4.7000008@oracle.com> David, (not a review, but I have a comment at the bottom) On 2013-09-11 13:06, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev/ > > Short version: use CLOCK_MONOTONIC with pthread_cond_t objects for > relative timed-waits. > > Long version - see below :) > > Thanks, > David > ----- > > Background: relative timed-waits (Thread.sleep, Object.wait, > LockSupport.parkNanos) should not be affected by changes to the > time-of-day clock. The linux implementation uses pthread_cond_timedwait > on default initialized pthread_cond_t objects. pthread_cond_timedwait > actually takes an absolute time and the default clock is CLOCK_REALTIME > (which is a time-of-day clock). You would expect then that changing the > time-of-day would impact these supposedly relative timed waits: time > going forward would cause early returns; time going backwards would > cause extended delays. But for many years it did not - the reason being > that the glibc/pthreads implementors had not implemented it to work that > way. Originally the monotonic clock didn't even exist so there was only > one way this could be implemented (and we had LinuxThreads vs NPTL etc > etc - lots of history). > > Skip forward to 2009 and glibc was modified to correct this behaviour - > but only on 64-bit linux (no idea why - the 32-bit variant was added > earlier this year but I don't know what glibc version that corresponds > to). For 64-bit this was, as I understand it, glibc 2.12. By coincidence > in 2009 I filed 6900441 as I knew we would have to change the > implementation when glibc was fixed - unfortunately I wasn't aware that > it actually had been fixed at that time. The bug was slated for future > work, I went on to other things, blah blah blah ... > > We didn't get a flurry of bug reports in 2009, nor 2010, 2011 ... why > not? Partly because people tend to avoid large jumps in system time and > this bug only becomes noticeable when "large" backward jumps occur and > threads 'hang'. (Forward jumps cause early returns that are either > filtered out or permitted as spurious-wakeups). And partly it seems > because it took time for glibc 2.12 to get into some Linux distributions > and for people to take up the new version. > > Skip forward to today and we are starting to see a number of reports > about this problem as people are now using the new glibc (and may have > been for a while) and also seeing time changes have unexpected impact on > their programs. So this needs to be fixed ASAP before it becomes a major > problem and will be backported to OpenJDK 7 and 6. > > The fix is relatively straight-forward: the pthread_cond_t objects used > for the relative timed-waits have to be associated with CLOCK_MONOTONIC > so that they are not affected by changes to the time-of-day clock. There > is a slight complication in that the LockSupport.park API supports both > a relative and absolute timed-wait so we need two different > pthread_cond_t each associated with different clocks. > > Notes: > > 1. This is a linux fix only. I don't know if we also have the problem on > other OS but it hasn't been flagged and while I will check, it is more > important to get this out for Linux ASAP. > > 2. Given the late stage of JDK 8 release cycle (to minimize risk), and > to ease backporting to 6 and 7, I made no attempt to do any kind of code > clean up here. This code is full of historical anachronisms and for Java > 9 I hope to see it all cleaned up, but for now all the baggage and > duplication must remain as-is. > > 3. We can obviously only fix this if we have a monotonic clock hence > that has to be used to guard the new code. These days it would be > extremely rare to not have the monotonic clock but I still use the guard. > > 4. CLOCK_MONOTONIC is not in fact completely immune to changes in the > time of day clock but it won't jump backwards. The new clock on the > block is CLOCK_MONOTONIC_RAW which should always advance at a constant > rate with no jumps. We have a RFE to start using CLOCK_MONOTONIC_RAW for > System.nanoTime(), and we would use it for the pthread_cond_t too, but > we can't use that until the JDK 8 build platform is updated to a linux > version that actually has that clock at build time. That update is very > near but not yet here so we stay with CLOCK_MONOTONIC. It seems like we already handle the fact that the build platform may not support CLOCK_MONOTONIC: 1371 #ifndef CLOCK_MONOTONIC 1372 #define CLOCK_MONOTONIC (1) 1373 #endif Is there something stopping us from #define:ing CLOCK_MONOTONIC_RAW ourselves as well? Do you plan to remove this #ifndef block when the build platform is upgraded? /Mikael From mikael.gerdin at oracle.com Thu Sep 12 00:33:41 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Sep 2013 09:33:41 +0200 Subject: RFR: 8023476: Metaspace capacity > reserved In-Reply-To: <20130911151821.GA3486@ehelin-thinkpad> References: <20130911151821.GA3486@ehelin-thinkpad> Message-ID: <52316E55.9030102@oracle.com> Erik, On 2013-09-11 17:18, Erik Helin wrote: > Hi all, > > this change is a first step to clean up the usage of words and bytes in > metaspace.cpp/hpp. The change includes: > - Appending function names with the unit of the size they return. All > functions in MetaspaceAux returning bytes are now ending in _bytes and > functions returning words ends in _words. > - Appending function that iterates over the ClassLoaderDataGraph with > _slow. These functions have also been made private since they should > only be used internally for verification purposes. > - Removing the function Metaspace::waste_bytes which isn't used > - Making sure MetaspaceAux::reserved_bytes actually returns bytes > instead of words. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8023476/webrev.00/ The change looks good. /Mikael > > Testing: > - JPRT > - hotspot/test/gc/metaspace > > Thanks, > Erik > From bengt.rutisson at oracle.com Thu Sep 12 01:11:17 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Sep 2013 10:11:17 +0200 Subject: Review request: 8024638: Count and expose the amount of committed memory in the metaspaces In-Reply-To: <5230DABE.10403@oracle.com> References: <523095EF.3030803@oracle.com> <5230DABE.10403@oracle.com> Message-ID: <52317725.9010602@oracle.com> Stefan, Looks good. For the record, Stefan and I talked about introducing some verification code to check that the reserved and committed sizes that the VirtualSpaceList keeps track of is the same as the sum of the corresponding values for all nodes. We agreed to add that as a separate change. Thanks, Bengt On 9/11/13 11:03 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ > > Further testing showed that one of the asserts in > actual_committed_size was incorrect when the the middle region of the > VirtualSpace was empty and the middle alignment was larger than the > other alignments. This can happen when large pages are used and the > size of the VirtualSpace is within the range [large_page_size, 2 * > large_page_size). > > I rewrote the asserts to handle that and similar cases. I also added > new unit test cases that provoked this incorrect assert. > > Thanks Erik Helin for finding this (and also for helping out with the > original patch). > > thanks, > StefanK > > On 9/11/13 6:10 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024547/webrev.00/ >> >> This change adds code to track the committed memory in the metaspaces. >> >> This fix is a prerequisite for: >> 8024547: MaxMetaspaceSize should limit the committed memory used by >> the metaspaces >> >> The patch is built upon this change, which is also out for review: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-September/010766.html >> >> >> Changes in the patch: >> >> - Renamed VirtualSpaceList::_virtual_space_total to >> VirtualSpaceList::_reserved_words. >> >> - Introduced a VirtualSpaceList::_committed_words. >> >> - Added a new function VirtualSpace::actual_committed_size(), which >> reports the memory committed by the OS. The per-existing function >> VirtualSpace::committed_size() only reports the amount of memory >> asked for by calls to VirtualSpace::expand_by, which can be >> significantly less because of OS allocation granularities and large >> pages. >> >> - Added code to tracks when the VirtualSpaces in the >> VirtualSpaceNodes are created, deleted, and expanded. >> >> - Added unit tests. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Thu Sep 12 02:06:53 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 11:06:53 +0200 Subject: Review request: 8024651: Remove the incorrect usage of Metablock::overhead() Message-ID: <5231842D.8020602@oracle.com> http://cr.openjdk.java.net/~stefank/8024651/webrev.00/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024651 Remove the unneeded Metablock::_overhead/overhead(). StefanK From 76069016 at qq.com Thu Sep 12 02:17:44 2013 From: 76069016 at qq.com (=?ISO-8859-1?B?SXNtbA==?=) Date: Thu, 12 Sep 2013 17:17:44 +0800 Subject: Is it possible to static link jvm? Message-ID: Hi, everyone! I am reading launcher code(hotspot7u\src\share\tools\launcher etc.) in the hotspot project and see some comments like this(in file hotspot7u\src\os\windows\launcher\java_md.c, line 434): jboolean LoadJavaVM(const char *jvmpath, InvocationFunctions *ifn) { #ifdef GAMMA /* JVM is directly linked with gamma launcher; no Loadlibrary() */ ifn->CreateJavaVM = JNI_CreateJavaVM; ifn->GetDefaultJavaVMInitArgs = JNI_GetDefaultJavaVMInitArgs; return JNI_TRUE; #else It seems that jvm could be staticly linked. So I just do some try. After some tiny modifications, I successfully compiled it and link the jvm. But when I run it, it fails with error "unable to find jvm.dll". I debug the code, and find the actual reason why it failes(src\share\vm\runtime\os.cpp, line 385): void* os::native_java_library() { dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "verify"); dll_load(buffer, ebuf, sizeof(ebuf)); // Load java dll dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "java"); _native_java_library = dll_load(buffer, ebuf, sizeof(ebuf)); verify.dll and java.dll is designed to be load here, and they all depends on jvm.dll! Now I do not how to do, any idea? From bengt.rutisson at oracle.com Thu Sep 12 02:17:51 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Sep 2013 11:17:51 +0200 Subject: Review request: 8024651: Remove the incorrect usage of Metablock::overhead() In-Reply-To: <5231842D.8020602@oracle.com> References: <5231842D.8020602@oracle.com> Message-ID: <523186BF.8090002@oracle.com> Stefan, Looks good. Bengt On 9/12/13 11:06 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024651/webrev.00/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024651 > > Remove the unneeded Metablock::_overhead/overhead(). > > StefanK From david.holmes at oracle.com Thu Sep 12 03:00:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 20:00:20 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <52316CB4.7000008@oracle.com> References: <52304EB5.7000603@oracle.com> <52316CB4.7000008@oracle.com> Message-ID: <523190B4.9090305@oracle.com> On 12/09/2013 5:26 PM, Mikael Gerdin wrote: > David, > > (not a review, but I have a comment at the bottom) > > On 2013-09-11 13:06, David Holmes wrote: >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/6900441/webrev/ >> >> Short version: use CLOCK_MONOTONIC with pthread_cond_t objects for >> relative timed-waits. >> >> Long version - see below :) >> >> 4. CLOCK_MONOTONIC is not in fact completely immune to changes in the >> time of day clock but it won't jump backwards. The new clock on the >> block is CLOCK_MONOTONIC_RAW which should always advance at a constant >> rate with no jumps. We have a RFE to start using CLOCK_MONOTONIC_RAW for >> System.nanoTime(), and we would use it for the pthread_cond_t too, but >> we can't use that until the JDK 8 build platform is updated to a linux >> version that actually has that clock at build time. That update is very >> near but not yet here so we stay with CLOCK_MONOTONIC. > > It seems like we already handle the fact that the build platform may not > support CLOCK_MONOTONIC: > 1371 #ifndef CLOCK_MONOTONIC > 1372 #define CLOCK_MONOTONIC (1) > 1373 #endif > > Is there something stopping us from #define:ing CLOCK_MONOTONIC_RAW > ourselves as well? Perhaps not, I hadn't considered that. > Do you plan to remove this #ifndef block when the build platform is > upgraded? It will get cleaned up at some point but perhaps not until 9. David > /Mikael From stefan.karlsson at oracle.com Thu Sep 12 03:36:09 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 12:36:09 +0200 Subject: Review request: 8024651: Remove the incorrect usage of Metablock::overhead() In-Reply-To: <523186BF.8090002@oracle.com> References: <5231842D.8020602@oracle.com> <523186BF.8090002@oracle.com> Message-ID: <52319919.1070602@oracle.com> On 09/12/2013 11:17 AM, Bengt Rutisson wrote: > > Stefan, > > Looks good. Thanks, Bengt. StefanK > > Bengt > > On 9/12/13 11:06 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024651/webrev.00/ >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024651 >> >> Remove the unneeded Metablock::_overhead/overhead(). >> >> StefanK > From stefan.karlsson at oracle.com Thu Sep 12 03:37:22 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 12:37:22 +0200 Subject: Review request: 8024638: Count and expose the amount of committed memory in the metaspaces In-Reply-To: <52317725.9010602@oracle.com> References: <523095EF.3030803@oracle.com> <5230DABE.10403@oracle.com> <52317725.9010602@oracle.com> Message-ID: <52319962.5030909@oracle.com> On 09/12/2013 10:11 AM, Bengt Rutisson wrote: > > Stefan, > > Looks good. Thanks, Bengt. StefanK > > For the record, Stefan and I talked about introducing some > verification code to check that the reserved and committed sizes that > the VirtualSpaceList keeps track of is the same as the sum of the > corresponding values for all nodes. We agreed to add that as a > separate change. > > Thanks, > Bengt > > On 9/11/13 11:03 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ >> >> Further testing showed that one of the asserts in >> actual_committed_size was incorrect when the the middle region of the >> VirtualSpace was empty and the middle alignment was larger than the >> other alignments. This can happen when large pages are used and the >> size of the VirtualSpace is within the range [large_page_size, 2 * >> large_page_size). >> >> I rewrote the asserts to handle that and similar cases. I also added >> new unit test cases that provoked this incorrect assert. >> >> Thanks Erik Helin for finding this (and also for helping out with the >> original patch). >> >> thanks, >> StefanK >> >> On 9/11/13 6:10 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00/ >>> >>> This change adds code to track the committed memory in the metaspaces. >>> >>> This fix is a prerequisite for: >>> 8024547: MaxMetaspaceSize should limit the committed memory used >>> by the metaspaces >>> >>> The patch is built upon this change, which is also out for review: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-September/010766.html >>> >>> >>> Changes in the patch: >>> >>> - Renamed VirtualSpaceList::_virtual_space_total to >>> VirtualSpaceList::_reserved_words. >>> >>> - Introduced a VirtualSpaceList::_committed_words. >>> >>> - Added a new function VirtualSpace::actual_committed_size(), which >>> reports the memory committed by the OS. The per-existing function >>> VirtualSpace::committed_size() only reports the amount of memory >>> asked for by calls to VirtualSpace::expand_by, which can be >>> significantly less because of OS allocation granularities and large >>> pages. >>> >>> - Added code to tracks when the VirtualSpaces in the >>> VirtualSpaceNodes are created, deleted, and expanded. >>> >>> - Added unit tests. >>> >>> thanks, >>> StefanK >> > From mikael.gerdin at oracle.com Thu Sep 12 03:46:31 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Sep 2013 12:46:31 +0200 Subject: Review request: 8024651: Remove the incorrect usage of Metablock::overhead() In-Reply-To: <523186BF.8090002@oracle.com> References: <5231842D.8020602@oracle.com> <523186BF.8090002@oracle.com> Message-ID: <52319B87.3040300@oracle.com> Stefan, On 2013-09-12 11:17, Bengt Rutisson wrote: > > Stefan, > > Looks good. > > Bengt > > On 9/12/13 11:06 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024651/webrev.00/ Ship it! /m >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024651 >> >> Remove the unneeded Metablock::_overhead/overhead(). >> >> StefanK > From niclas.adlertz at oracle.com Thu Sep 12 03:49:35 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Thu, 12 Sep 2013 10:49:35 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130912105002.D29F86274E@hg.openjdk.java.net> Changeset: ceda33ff54a3 Author: iignatyev Date: 2013-09-05 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ceda33ff54a3 8012447: Java CTW implementation Reviewed-by: vlivanov, kvn, twisti ! test/gc/TestVerifyDuringStartup.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/ctw/Makefile + test/testlibrary/ctw/README + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java + test/testlibrary/ctw/test/Bar.java + test/testlibrary/ctw/test/ClassesDirTest.java + test/testlibrary/ctw/test/ClassesListTest.java + test/testlibrary/ctw/test/CtwTest.java + test/testlibrary/ctw/test/Foo.java + test/testlibrary/ctw/test/JarDirTest.java + test/testlibrary/ctw/test/JarsTest.java + test/testlibrary/ctw/test/classes.lst + test/testlibrary/whitebox/Makefile Changeset: cd16d587b0fa Author: adlertz Date: 2013-09-09 19:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd16d587b0fa Merge Changeset: 72a567cce06f Author: anoll Date: 2013-09-10 07:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/72a567cce06f 8024473: Remove unused macro: IRT_ENTRY_FOR_NMETHOD Summary: Removed unused macro Reviewed-by: kvn, adlertz ! src/share/vm/runtime/interfaceSupport.hpp Changeset: edb5ab0f3fe5 Author: vlivanov Date: 2013-09-10 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/edb5ab0f3fe5 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: rbackman, twisti, kvn Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/accessFlags.hpp Changeset: e0d33d2ce5aa Author: vlivanov Date: 2013-09-10 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0d33d2ce5aa Merge Changeset: 34bd5e86aadb Author: adlertz Date: 2013-09-11 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/34bd5e86aadb 8010941: MinJumpTableSize is set to 18, investigate if that's still optimal Summary: Lowered the MinJumpTableSize for each platform Reviewed-by: kvn ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/share/vm/opto/c2_globals.hpp Changeset: 0821b5d72ca8 Author: adlertz Date: 2013-09-12 09:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0821b5d72ca8 Merge From Alan.Bateman at oracle.com Thu Sep 12 04:10:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Sep 2013 12:10:03 +0100 Subject: Anything in hs25-b47 or b47 that would cause a significant performance regression? Message-ID: <5231A10B.7090109@oracle.com> This is a long shot but does anyone know of any performance regressions that might have crept in recently, specifically in jdk8-b105 or jdk8-b106 (hs25-b47 or hs25-b48). jdk8/tl was sync'ed up to jdk8-b106 (it had been at b104) last Friday and since then several of us have noticed significant slowdowns (20-30%) in the time is takes to run the jdk tests. The jdk tests run in agent VM mode that should mostly eliminate startup for most of the tests. As jdk8/tl is always ahead of jdk8/jdk8 with library changes then it means that the only interesting changes that the sync up brought in is the HotSpot changes. I don't think anyone of has had the time to attempt to bisect this yet (or know if this is all or only some OS/arch) and this mail is just to see whether it rings any bells with anyone. -Alan From stefan.karlsson at oracle.com Thu Sep 12 04:18:24 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 13:18:24 +0200 Subject: Review request: 8024651: Remove the incorrect usage of Metablock::overhead() In-Reply-To: <52319B87.3040300@oracle.com> References: <5231842D.8020602@oracle.com> <523186BF.8090002@oracle.com> <52319B87.3040300@oracle.com> Message-ID: <5231A300.3040209@oracle.com> On 09/12/2013 12:46 PM, Mikael Gerdin wrote: > Stefan, > > On 2013-09-12 11:17, Bengt Rutisson wrote: >> >> Stefan, >> >> Looks good. >> >> Bengt >> >> On 9/12/13 11:06 AM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8024651/webrev.00/ > > Ship it! OK. StefanK > > /m > >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024651 >>> >>> Remove the unneeded Metablock::_overhead/overhead(). >>> >>> StefanK >> From goetz.lindenmaier at sap.com Thu Sep 12 04:42:50 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 12 Sep 2013 11:42:50 +0000 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <523110CC.1040307@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> <523110CC.1040307@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> Hi Vladimir, > Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp > to sharedRuntime_ppc.cpp? They are static and not used in any other places. I really would like to keep this code in the shared file because: - The code is completely plarform independent. - The feature needs several shared changes, so I think it's natural to keep all it's platform independent parts in the shared files. - Internally, we use it also for zArch, so for us it would reduce code duplication to have it in the shared file. > Why only intrinsify_fill changed? What about arraycopy and other stubs > which use int parameter? Yes, that looks strange. For stub calls that should not be needed, as we also implement the callee. I'll investigate this in our VM, and try to remove the change to runtime.cpp and loopTransform.cpp. I'll come up with a new webrev then. Thanks for pointing me to this! > loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also > you can use (t == T_INT || is_subword_type(t)) check instead for int types. Above, a MoveF2I is issued, therefore ConvI2L works. Probably conversion is pointless, but the type is correct then. Thanks for the review and for adapting the closed stuff to 0112. Best regards, Goetz. On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: > Hi, > > This is the first of about 10 changes taking us to a rudimentary c2 > compiler on ppc64. > > Some platforms, as ppc and s390x/zArch require that 32-bit ints are > passed as 64-bit values to C functions. This change adds support to > adapt the signature and to issue proper casts to c2-compiled stubs. The > functions are used in generate_native_wrapper(). We also need to adapt > the signature in PhaseIdealLoop::intrinsify_fill(). > > We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with > > enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing > > platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by > > ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp > > line 1752 ff. > > > > http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ > > Please review and test this change. > > Best regards, > > Goetz. > From coleen.phillimore at oracle.com Thu Sep 12 06:26:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 09:26:12 -0400 Subject: Review request: 8024651: Remove the incorrect usage of Metablock::overhead() In-Reply-To: <5231842D.8020602@oracle.com> References: <5231842D.8020602@oracle.com> Message-ID: <5231C0F4.4020406@oracle.com> Maybe Metablock::overhead was going to be some debugging/padding code. Removal looks good to me. Coleen On 9/12/2013 5:06 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024651/webrev.00/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024651 > > Remove the unneeded Metablock::_overhead/overhead(). > > StefanK From vladimir.x.ivanov at oracle.com Thu Sep 12 07:46:01 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 12 Sep 2013 18:46:01 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <522DAFF5.3030905@oracle.com> References: <522DAFF5.3030905@oracle.com> Message-ID: <5231D3A9.9060208@oracle.com> Revised version: http://cr.openjdk.java.net/~vlivanov/8023134/webrev.02/ Turned off LogVMOutput for debug builds by default and implicitly turn it on if some flag is specified which may dump useful info in the log file. Best regards, Vladimir Ivanov On 9/9/13 3:24 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ > 7 lines changed: 4 ins; 0 del; 3 mod > > Added pid of the Java process to default name of VM log file: > - old: hotspot.log > - new: hotspot_pid{pid}.log > > It allows to avoid hotspot.log overwrite/corruption in multi-VM test > scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. > > Thanks! > > Best regards, > Vladimir Ivanov From daniel.daugherty at oracle.com Thu Sep 12 08:14:38 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Sep 2013 09:14:38 -0600 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5230F96A.30306@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> Message-ID: <5231DA5E.9070102@oracle.com> On 9/11/13 5:14 PM, David Holmes wrote: > updated webrev: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ Looks good. Possibly modulo one comment below... > On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: > >> line 5541: assert_status(status == 0, status, "clock_gettime"); >> line 5553: assert(status == 0, "gettimeofday"); >> So why is one an assert_status() call and the other is a >> plain old assert() call? > > Different API's. The old unix API's, like gettimeofday return -1 on > error and set errno. The "modern" posix APIs, eg pthread APIs and > clock_gettime etc, return the actual error code on error - hence > assert_status can be used to show the actual error in that case. I don't quite get what you're trying to say here. It seems that both calls are trying to verify that "status == 0". Or are you saying that: assert_status(status == 0, status, "gettimeofday"); is kind of a waste because "status" always be either "0" or "-1". So how about this: assert_status(status == 0, errno, "gettimeofday"); instead? That pattern should work to get more info. Dan From stefan.karlsson at oracle.com Thu Sep 12 08:18:14 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 17:18:14 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize Message-ID: <5231DB36.6080101@oracle.com> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ - Limit MetaspaceSize to MaxMetaspaceSize - Make sure we don't align down to 0. - jtreg test Note that this patch also adds/changes some functionality in the OutputAnalyzer in test/testlibrary. thanks, StefanK From bob.vandette at oracle.com Thu Sep 12 08:43:55 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 12 Sep 2013 11:43:55 -0400 Subject: Is it possible to static link jvm? In-Reply-To: References: Message-ID: <3114BC45-D10F-4CE3-9AA4-F6AF1DBC75D3@oracle.com> The hotspot sources do not currently support statically linking. There are a number of places in the hotspot sources that would have to be modified in order to support this. It is only in JDK 8 that we modified the JNI and JVMTI specifications to allow statically linked JNI libraries. This is the first step in allowing a completely statically linked VM and Java runtime. Bob. On Sep 12, 2013, at 5:17 AM, Isml wrote: > Hi, everyone! > I am reading launcher code(hotspot7u\src\share\tools\launcher etc.) in the hotspot project and see some comments like this(in file hotspot7u\src\os\windows\launcher\java_md.c, line 434): > > jboolean > LoadJavaVM(const char *jvmpath, InvocationFunctions *ifn) > { > #ifdef GAMMA > /* JVM is directly linked with gamma launcher; no Loadlibrary() */ > ifn->CreateJavaVM = JNI_CreateJavaVM; > ifn->GetDefaultJavaVMInitArgs = JNI_GetDefaultJavaVMInitArgs; > return JNI_TRUE; > #else > > It seems that jvm could be staticly linked. So I just do some try. After some tiny modifications, I successfully compiled it and link the jvm. But when I run it, it fails with error "unable to find jvm.dll". I debug the code, and find the actual reason why it failes(src\share\vm\runtime\os.cpp, line 385): > > void* os::native_java_library() { > dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "verify"); > dll_load(buffer, ebuf, sizeof(ebuf)); > // Load java dll > dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "java"); > _native_java_library = dll_load(buffer, ebuf, sizeof(ebuf)); > > verify.dll and java.dll is designed to be load here, and they all depends on jvm.dll! > Now I do not how to do, any idea? From christian.thalinger at oracle.com Thu Sep 12 09:42:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 09:42:06 -0700 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <5231D3A9.9060208@oracle.com> References: <522DAFF5.3030905@oracle.com> <5231D3A9.9060208@oracle.com> Message-ID: <46ECDE0B-E16C-454C-9AC3-25D0BFDF3AAE@oracle.com> Looks good. -- Chris On Sep 12, 2013, at 7:46 AM, Vladimir Ivanov wrote: > Revised version: > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.02/ > > Turned off LogVMOutput for debug builds by default and implicitly turn it on if some flag is specified which may dump useful info in the log file. > > Best regards, > Vladimir Ivanov > > On 9/9/13 3:24 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> Added pid of the Java process to default name of VM log file: >> - old: hotspot.log >> - new: hotspot_pid{pid}.log >> >> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From jesper.wilhelmsson at oracle.com Thu Sep 12 09:52:20 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Sep 2013 18:52:20 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5231DB36.6080101@oracle.com> References: <5231DB36.6080101@oracle.com> Message-ID: <5231F144.3070001@oracle.com> Looks good! /Jesper Stefan Karlsson skrev 12/9/13 5:18 PM: > http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ > > - Limit MetaspaceSize to MaxMetaspaceSize > - Make sure we don't align down to 0. > - jtreg test > > Note that this patch also adds/changes some functionality in the OutputAnalyzer > in test/testlibrary. > > thanks, > StefanK From stefan.karlsson at oracle.com Thu Sep 12 09:56:40 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 18:56:40 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5231F144.3070001@oracle.com> References: <5231DB36.6080101@oracle.com> <5231F144.3070001@oracle.com> Message-ID: <5231F248.9070706@oracle.com> On 9/12/13 6:52 PM, Jesper Wilhelmsson wrote: > Looks good! Thanks, Jesper. StefanK > /Jesper > > Stefan Karlsson skrev 12/9/13 5:18 PM: >> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ >> >> - Limit MetaspaceSize to MaxMetaspaceSize >> - Make sure we don't align down to 0. >> - jtreg test >> >> Note that this patch also adds/changes some functionality in the >> OutputAnalyzer >> in test/testlibrary. >> >> thanks, >> StefanK From vladimir.kozlov at oracle.com Thu Sep 12 09:57:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Sep 2013 09:57:33 -0700 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <5231D3A9.9060208@oracle.com> References: <522DAFF5.3030905@oracle.com> <5231D3A9.9060208@oracle.com> Message-ID: <5231F27D.6010207@oracle.com> Good. Vladimir On 9/12/13 7:46 AM, Vladimir Ivanov wrote: > Revised version: > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.02/ > > Turned off LogVMOutput for debug builds by default and implicitly turn > it on if some flag is specified which may dump useful info in the log file. > > Best regards, > Vladimir Ivanov > > On 9/9/13 3:24 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> Added pid of the Java process to default name of VM log file: >> - old: hotspot.log >> - new: hotspot_pid{pid}.log >> >> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From christian.thalinger at oracle.com Thu Sep 12 09:58:57 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 09:58:57 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <52310C27.2060107@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> Message-ID: On Sep 11, 2013, at 5:34 PM, David Holmes wrote: > Hi Chris, > > There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: > > + if (is_constant_in_binary()) { > + fatal(err_msg("flag is constant: %s", _name)); > > into a check_writable() method so that it isn't duplicated so much. Good point. I made that change: http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html > > I also wonder whether a ConstFlag sub/superclass would simplify this at all? Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. > > That aside I'm curious why the minimal VM size change is only 22K when client is 32K? The 32-bit product build also contains the server compiler. -- Chris > > Thanks, > David > > On 11/09/2013 10:56 AM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >> >> 8024545: make develop and notproduct flag values available in product builds >> Reviewed-by: >> >> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >> >> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >> >> Before: >> >> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >> Attaching to process 9399, please wait... >> hsdb> flags -nd >> InitialHeapSize = 495006528 5 >> MaxHeapSize = 7920943104 5 >> UseCompressedKlassPointers = true 5 >> UseCompressedOops = true 5 >> UseParallelGC = true 5 >> hsdb> flags InlineMathNatives >> Couldn't find flag: InlineMathNatives >> >> After: >> >> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >> Attaching to process 3726, please wait... >> hsdb> flags -nd >> InitialHeapSize = 495006528 5 >> MaxHeapSize = 7920943104 5 >> UseCompressedKlassPointers = true 5 >> UseCompressedOops = true 5 >> UseParallelGC = true 5 >> hsdb> flags InlineMathNatives >> InlineMathNatives = true 0 >> >> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >> >> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >> >> The output for product builds is unchanged. >> From staffan.larsen at oracle.com Thu Sep 12 11:01:12 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Sep 2013 21:01:12 +0300 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <5231D3A9.9060208@oracle.com> References: <522DAFF5.3030905@oracle.com> <5231D3A9.9060208@oracle.com> Message-ID: <6067819D-BAE6-4985-A172-A59B8CFF9CBF@oracle.com> Looks good. Thanks for the changes. /Staffan On 12 sep 2013, at 17:46, Vladimir Ivanov wrote: > Revised version: > http://cr.openjdk.java.net/~vlivanov/8023134/webrev.02/ > > Turned off LogVMOutput for debug builds by default and implicitly turn it on if some flag is specified which may dump useful info in the log file. > > Best regards, > Vladimir Ivanov > > On 9/9/13 3:24 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> Added pid of the Java process to default name of VM log file: >> - old: hotspot.log >> - new: hotspot_pid{pid}.log >> >> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From stefan.karlsson at oracle.com Thu Sep 12 11:27:38 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 20:27:38 +0200 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <6067819D-BAE6-4985-A172-A59B8CFF9CBF@oracle.com> References: <522DAFF5.3030905@oracle.com> <5231D3A9.9060208@oracle.com> <6067819D-BAE6-4985-A172-A59B8CFF9CBF@oracle.com> Message-ID: <5232079A.1020408@oracle.com> On 9/12/13 8:01 PM, Staffan Larsen wrote: > Looks good. Thanks for the changes. No review, but thanks for turning off LogVMOutput. StefanK > > /Staffan > > On 12 sep 2013, at 17:46, Vladimir Ivanov wrote: > >> Revised version: >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.02/ >> >> Turned off LogVMOutput for debug builds by default and implicitly turn it on if some flag is specified which may dump useful info in the log file. >> >> Best regards, >> Vladimir Ivanov >> >> On 9/9/13 3:24 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>> 7 lines changed: 4 ins; 0 del; 3 mod >>> >>> Added pid of the Java process to default name of VM log file: >>> - old: hotspot.log >>> - new: hotspot_pid{pid}.log >>> >>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From serguei.spitsyn at oracle.com Thu Sep 12 11:37:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 11:37:09 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52313BE7.7030704@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52313BE7.7030704@oracle.com> Message-ID: <523209D5.1090101@oracle.com> On 9/11/13 8:58 PM, David Holmes wrote: > On 12/09/2013 1:54 PM, David Holmes wrote: >> Hi Dmitry, > > Sorry Serguei. I'm Ok. :) Thank you for review! Thanks, Serguei > > David > >> It seems odd that you install the new_method even if there was an >> exception. What if the new_method is not valid because of the >> exception ? >> >> Also once you've cleared the exception and returned false, the user has >> no information as to why this failed. I understand we don't want to hit >> the guarantee here, but it seems there is a hole in the error flow. >> >> David >> >> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>> >>> >>> >>> Summary: >>> Handle pending exceptions instead of firing a guarantee() in the >>> JVMTI rewrite_cp_refs_in_method(). >>> >>> >>> Testing: >>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>> Metaspace memory, >>> nsk.jvmti.testlist, >>> nsk.jdi.testlist, >>> Jtreg java/lang/instrument >>> >>> Thanks, >>> Serguei From vladimir.x.ivanov at oracle.com Thu Sep 12 12:06:31 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 12 Sep 2013 23:06:31 +0400 Subject: RFR (XS): 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) In-Reply-To: <6067819D-BAE6-4985-A172-A59B8CFF9CBF@oracle.com> References: <522DAFF5.3030905@oracle.com> <5231D3A9.9060208@oracle.com> <6067819D-BAE6-4985-A172-A59B8CFF9CBF@oracle.com> Message-ID: <523210B7.5060407@oracle.com> Chris, Vladimir, Staffan, thank you for review. Best regards, Vladimir Ivanov On 9/12/13 10:01 PM, Staffan Larsen wrote: > Looks good. Thanks for the changes. > > /Staffan > > On 12 sep 2013, at 17:46, Vladimir Ivanov wrote: > >> Revised version: >> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.02/ >> >> Turned off LogVMOutput for debug builds by default and implicitly turn it on if some flag is specified which may dump useful info in the log file. >> >> Best regards, >> Vladimir Ivanov >> >> On 9/9/13 3:24 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8023134/webrev.00/ >>> 7 lines changed: 4 ins; 0 del; 3 mod >>> >>> Added pid of the Java process to default name of VM log file: >>> - old: hotspot.log >>> - new: hotspot_pid{pid}.log >>> >>> It allows to avoid hotspot.log overwrite/corruption in multi-VM test >>> scenarios and simplifies hs_err/ciReplay/hotspot.log files matching. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov > From serguei.spitsyn at oracle.com Thu Sep 12 12:21:43 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 12:21:43 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52313ADF.2060505@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> Message-ID: <52321447.4000405@oracle.com> On 9/11/13 8:54 PM, David Holmes wrote: > Hi Dmitry, > > It seems odd that you install the new_method even if there was an > exception. What if the new_method is not valid because of the exception ? Coleen suggested this fragment. New methods will be deallocated with the scratch class in a case of exception. It is handled in the doit_prologue where the scratch classes are added to the CL deallocation list. > > Also once you've cleared the exception and returned false, the user > has no information as to why this failed. I understand we don't want > to hit the guarantee here, but it seems there is a hole in the error > flow. This issue is fixed in a separate bug fix for 8024346 (see another review request). Sorry for the confusion here. The whole error flow is not perfect but I'm not targetting to make it perfect now. Multiple bugs on the limited Metaspace topic were filed by Stefan: 8017230, 8024345, 8024346. My role is to apply/test fixes suggested by Stefan and Coleen in the order the issues were discovered. Thanks, Serguei > > David > > On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >> >> >> Summary: >> Handle pending exceptions instead of firing a guarantee() in the >> JVMTI rewrite_cp_refs_in_method(). >> >> >> Testing: >> UTE tests - in progress: vm.quick-pcl.testlist with limited >> Metaspace memory, >> nsk.jvmti.testlist, >> nsk.jdi.testlist, >> Jtreg java/lang/instrument >> >> Thanks, >> Serguei From stefan.karlsson at oracle.com Thu Sep 12 12:58:26 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 21:58:26 +0200 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52321447.4000405@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> Message-ID: <52321CE2.9020307@oracle.com> On 9/12/13 9:21 PM, serguei.spitsyn at oracle.com wrote: > On 9/11/13 8:54 PM, David Holmes wrote: >> Hi Dmitry, >> >> It seems odd that you install the new_method even if there was an >> exception. What if the new_method is not valid because of the >> exception ? > > Coleen suggested this fragment. > New methods will be deallocated with the scratch class in a case of > exception. > It is handled in the doit_prologue where the scratch classes are added > to the CL deallocation list. > >> >> Also once you've cleared the exception and returned false, the user >> has no information as to why this failed. I understand we don't want >> to hit the guarantee here, but it seems there is a hole in the error >> flow. > > This issue is fixed in a separate bug fix for 8024346 (see another > review request). > Sorry for the confusion here. > > The whole error flow is not perfect but I'm not targetting to make it > perfect now. > Multiple bugs on the limited Metaspace topic were filed by Stefan: > 8017230, 8024345, 8024346. > My role is to apply/test fixes suggested by Stefan and Coleen in the > order the issues were discovered. > Just understand that my suggested patches were just temporary patches to get me past the bugs, not final fixes. thanks, StefanK > > Thanks, > Serguei > >> >> David >> >> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>> >>> >>> Summary: >>> Handle pending exceptions instead of firing a guarantee() in the >>> JVMTI rewrite_cp_refs_in_method(). >>> >>> >>> Testing: >>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>> Metaspace memory, >>> nsk.jvmti.testlist, >>> nsk.jdi.testlist, >>> Jtreg java/lang/instrument >>> >>> Thanks, >>> Serguei > From vladimir.kozlov at oracle.com Thu Sep 12 13:01:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Sep 2013 13:01:52 -0700 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> <523110CC.1040307@oracle.com> <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> Message-ID: <52321DB0.1050103@oracle.com> On 9/12/13 4:42 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp >> to sharedRuntime_ppc.cpp? They are static and not used in any other places. > I really would like to keep this code in the shared file because: > - The code is completely plarform independent. > - The feature needs several shared changes, so I think it's natural to keep all > it's platform independent parts in the shared files. > - Internally, we use it also for zArch, so for us it would reduce code duplication > to have it in the shared file. My concern is about VM size on platforms which do not need this. I wanted to suggest to put it under #ifdef but it will be ugly. > >> Why only intrinsify_fill changed? What about arraycopy and other stubs >> which use int parameter? > Yes, that looks strange. For stub calls that should not be needed, as > we also implement the callee. I'll investigate this in our VM, and try > to remove the change to runtime.cpp and loopTransform.cpp. > I'll come up with a new webrev then. Thanks for pointing me to this! > >> loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also >> you can use (t == T_INT || is_subword_type(t)) check instead for int types. > Above, a MoveF2I is issued, therefore ConvI2L works. Probably conversion > is pointless, but the type is correct then. I missed MoveF2I. Okay then. Thanks, Vladimir > > Thanks for the review and for adapting the closed stuff to 0112. > > Best regards, > Goetz. > > > On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> This is the first of about 10 changes taking us to a rudimentary c2 >> compiler on ppc64. >> >> Some platforms, as ppc and s390x/zArch require that 32-bit ints are >> passed as 64-bit values to C functions. This change adds support to >> adapt the signature and to issue proper casts to c2-compiled stubs. The >> functions are used in generate_native_wrapper(). We also need to adapt >> the signature in PhaseIdealLoop::intrinsify_fill(). >> >> We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with >> >> enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing >> >> platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by >> >> ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp >> >> line 1752 ff. >> >> >> >> http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ >> >> Please review and test this change. >> >> Best regards, >> >> Goetz. >> From serguei.spitsyn at oracle.com Thu Sep 12 13:03:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 13:03:09 -0700 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <52313E63.8010904@oracle.com> References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com> Message-ID: <52321DFD.3070904@oracle.com> On 9/11/13 9:09 PM, David Holmes wrote: > Hi Serguei, > > This is more consistent with the surrounding code, but: > > 1. Why no RC_TRACE_WITH_THREAD for this case? Ok, I'll add tracing code. > > 2. If an exception is pending, that isn't OOME, shouldn't "res" > already not be JVMTI_ERROR_NONE and so res should be returned in the > non-OOME case? Initially it was my concern as well. But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL are expected from the merge_cp_and_rewrite(). So, it is better to keep it simple as in the webrev. Thanks, Serguei > > David > > On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: >> >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 >> >> >> >> Summary: >> Pending exceptions must be handled properly after a call to the JVMTI >> merge_cp_and_rewrite. >> >> >> >> Testing: >> UTE tests - in progress: vm.quick-pcl.testlist with limited >> Metaspace memory, >> nsk.jvmti.testlist, >> nsk.jdi.testlist, >> Jtreg java/lang/instrument >> >> Thanks, >> Serguei >> From serguei.spitsyn at oracle.com Thu Sep 12 13:08:16 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 13:08:16 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52321CE2.9020307@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> <52321CE2.9020307@oracle.com> Message-ID: <52321F30.9030102@oracle.com> On 9/12/13 12:58 PM, Stefan Karlsson wrote: > On 9/12/13 9:21 PM, serguei.spitsyn at oracle.com wrote: >> On 9/11/13 8:54 PM, David Holmes wrote: >>> Hi Dmitry, >>> >>> It seems odd that you install the new_method even if there was an >>> exception. What if the new_method is not valid because of the >>> exception ? >> >> Coleen suggested this fragment. >> New methods will be deallocated with the scratch class in a case of >> exception. >> It is handled in the doit_prologue where the scratch classes are >> added to the CL deallocation list. >> >>> >>> Also once you've cleared the exception and returned false, the user >>> has no information as to why this failed. I understand we don't want >>> to hit the guarantee here, but it seems there is a hole in the error >>> flow. >> >> This issue is fixed in a separate bug fix for 8024346 (see another >> review request). >> Sorry for the confusion here. >> >> The whole error flow is not perfect but I'm not targetting to make it >> perfect now. >> Multiple bugs on the limited Metaspace topic were filed by Stefan: >> 8017230, 8024345, 8024346. >> My role is to apply/test fixes suggested by Stefan and Coleen in the >> order the issues were discovered. >> > Just understand that my suggested patches were just temporary patches > to get me past the bugs, not final fixes. Yes, of course. It is my resp. to double-check and make it final. But you deserved the credit for this investigation anyway. :) Thanks, Serguei > > thanks, > StefanK >> >> Thanks, >> Serguei >> >>> >>> David >>> >>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>>> >>>> >>>> Summary: >>>> Handle pending exceptions instead of firing a guarantee() in the >>>> JVMTI rewrite_cp_refs_in_method(). >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>> Metaspace memory, >>>> nsk.jvmti.testlist, >>>> nsk.jdi.testlist, >>>> Jtreg java/lang/instrument >>>> >>>> Thanks, >>>> Serguei >> > From stefan.karlsson at oracle.com Thu Sep 12 13:22:28 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Sep 2013 22:22:28 +0200 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <523221AB.6040103@oracle.com> References: <523221AB.6040103@oracle.com> Message-ID: <52322284.4000601@oracle.com> Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this change code that are shared between different HotSpot sub-components. StefanK -------- Original Message -------- Subject: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty Date: Thu, 12 Sep 2013 22:18:51 +0200 From: Stefan Karlsson To: hotspot-gc-dev at openjdk.java.net http://cr.openjdk.java.net/~stefank/8024752/webrev.00 The output you get when turning on the TraceMetadata* flags end up in different files. This makes these flags hard to use. The patch directs the output to the gclog_or_tty output stream. thanks, StefanK From serguei.spitsyn at oracle.com Thu Sep 12 14:35:13 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 14:35:13 -0700 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <52313D34.5090605@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> Message-ID: <52323391.3050108@oracle.com> On 9/11/13 9:04 PM, David Holmes wrote: > Hi Serguei, > > Typo: > > 2489 // scratch_cp is a merged constant po/ ol Fixed, thanks! > > > In VM_RedefineClasses::set_new_constant_pool do you not need to > de-allocate smaller_cp if you return due to an exception here: > > 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1, > CHECK); Good catch. It is better to deallocate it even if it is not very useful. The only exception possible here is an OOME (Metadata shortage). Thanks, Serguei > > David > ----- > > On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >> >> >> >> Summary: >> The OOME's in the JVMTI merge_cp_and_rewrite and >> set_new_constant_pool must be handled correctly. >> >> >> Testing: >> UTE tests - in progress: vm.quick-pcl.testlist with limited >> Metaspace memory, >> nsk.jvmti.testlist, >> nsk.jdi.testlist, >> Jtreg java/lang/instrument >> >> Thanks, >> Serguei From john.coomes at oracle.com Thu Sep 12 14:37:42 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:37:42 +0000 Subject: hg: hsx/hotspot-main: 2 new changesets Message-ID: <20130912213743.3A02A62785@hg.openjdk.java.net> Changeset: 0874bb4707b7 Author: omajid Date: 2013-09-11 12:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0874bb4707b7 8024320: Add s390(x) detection to platform.m4 Reviewed-by: erikj, ihse, dsamersoff ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: 14fe208b657c Author: cl Date: 2013-09-12 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/14fe208b657c Added tag jdk8-b107 for changeset 0874bb4707b7 ! .hgtags From john.coomes at oracle.com Thu Sep 12 14:37:53 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:37:53 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b107 for changeset 23fc34133152 Message-ID: <20130912213757.25DA662786@hg.openjdk.java.net> Changeset: 260f00a95705 Author: cl Date: 2013-09-12 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/260f00a95705 Added tag jdk8-b107 for changeset 23fc34133152 ! .hgtags From john.coomes at oracle.com Thu Sep 12 14:38:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:38:10 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b107 for changeset d6a32e3831aa Message-ID: <20130912213822.D320562787@hg.openjdk.java.net> Changeset: 8ade3eed63da Author: cl Date: 2013-09-12 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/8ade3eed63da Added tag jdk8-b107 for changeset d6a32e3831aa ! .hgtags From john.coomes at oracle.com Thu Sep 12 14:38:33 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:38:33 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b107 for changeset e3c9328f7563 Message-ID: <20130912213841.928FA62788@hg.openjdk.java.net> Changeset: d1ea68556fd7 Author: cl Date: 2013-09-12 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d1ea68556fd7 Added tag jdk8-b107 for changeset e3c9328f7563 ! .hgtags From john.coomes at oracle.com Thu Sep 12 14:38:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:38:56 +0000 Subject: hg: hsx/hotspot-main/jdk: 2 new changesets Message-ID: <20130912214108.5BE1662789@hg.openjdk.java.net> Changeset: eea685b9ccaa Author: amurillo Date: 2013-09-10 05:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eea685b9ccaa 8024515: ProblemList.txt updates to exclude tests that fail with hs25-b49 Reviewed-by: alanb, chegar ! test/ProblemList.txt Changeset: b67c8099ba28 Author: cl Date: 2013-09-12 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b67c8099ba28 Added tag jdk8-b107 for changeset eea685b9ccaa ! .hgtags From john.coomes at oracle.com Thu Sep 12 14:42:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:42:24 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b107 for changeset 3f274927ec18 Message-ID: <20130912214238.ECAE16278B@hg.openjdk.java.net> Changeset: 1b7f5a27c4ba Author: cl Date: 2013-09-12 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1b7f5a27c4ba Added tag jdk8-b107 for changeset 3f274927ec18 ! .hgtags From john.coomes at oracle.com Thu Sep 12 14:42:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Sep 2013 21:42:49 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b107 for changeset f35e1255024b Message-ID: <20130912214254.CB8BE6278C@hg.openjdk.java.net> Changeset: a1f980cc1355 Author: cl Date: 2013-09-12 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a1f980cc1355 Added tag jdk8-b107 for changeset f35e1255024b ! .hgtags From erik.helin at oracle.com Thu Sep 12 14:46:01 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 12 Sep 2013 23:46:01 +0200 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data Message-ID: <20130912214601.GC4100@ehelin-thinkpad> Hi all, this patch fixes some issues with memory pools and the performance counter reporting slightly different numbers for metaspace. I've also updated two jtreg tests as well as added a new one to test the change. InputArguments.java in the testlibrary is updated as well. InputArguments.contains now takes a prefix as a parameter instead of the exact name of a flag. This makes it possible to check if a flag expecting a value has been set. For example, -XX:MaxMetaspaceSize=100m can be checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). Webrev: http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ Testing: - JPRT - hotspot/test/gc (including updated and new tests) Thanks, Erik From david.holmes at oracle.com Thu Sep 12 14:47:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 07:47:32 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5231DA5E.9070102@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> Message-ID: <52323674.6060709@oracle.com> Hi Dan, I found a bug in the assertion related logic - new webrev: http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ For the untimed case in park I wasn't setting the _cur_index value (I was implicitly using zero) and so the assertion it wasn't -1 was failing in unpark. With regard to assert versus assert_status - yes this would work: assert_status(status == 0, errno, "gettimeofday"); I had never considered that. :) When I added assert_status to diagnoze a particular issue I never attempted to change all the existing asserts on the library calls. So we have a lot of simple "assert(status==0,"invariant") where assert_status could have been used, as well as the old gettimeofday style calls. Do you want me to change them all in os_linux.cpp? Thanks, David On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: > On 9/11/13 5:14 PM, David Holmes wrote: >> updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ > > Looks good. Possibly modulo one comment below... > > >> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >> >>> line 5541: assert_status(status == 0, status, "clock_gettime"); >>> line 5553: assert(status == 0, "gettimeofday"); >>> So why is one an assert_status() call and the other is a >>> plain old assert() call? >> >> Different API's. The old unix API's, like gettimeofday return -1 on >> error and set errno. The "modern" posix APIs, eg pthread APIs and >> clock_gettime etc, return the actual error code on error - hence >> assert_status can be used to show the actual error in that case. > > I don't quite get what you're trying to say here. > It seems that both calls are trying to verify > that "status == 0". Or are you saying that: > > assert_status(status == 0, status, "gettimeofday"); > > is kind of a waste because "status" always be either "0" or "-1". > So how about this: > > assert_status(status == 0, errno, "gettimeofday"); > > instead? That pattern should work to get more info. > > Dan > From vladimir.kozlov at oracle.com Thu Sep 12 16:30:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Sep 2013 16:30:17 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> Message-ID: <52324E89.9060006@oracle.com> Christian, Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? It would be nice enumerate flag's type and use int instead of strings: enum { bool_flag = 1, intx_flag = 2, + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, Thanks, Vladimir On 9/12/13 9:58 AM, Christian Thalinger wrote: > > On Sep 11, 2013, at 5:34 PM, David Holmes wrote: > >> Hi Chris, >> >> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >> >> + if (is_constant_in_binary()) { >> + fatal(err_msg("flag is constant: %s", _name)); >> >> into a check_writable() method so that it isn't duplicated so much. > > Good point. I made that change: > > http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html > >> >> I also wonder whether a ConstFlag sub/superclass would simplify this at all? > > Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. > >> >> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? > > The 32-bit product build also contains the server compiler. > > -- Chris > >> >> Thanks, >> David >> >> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>> >>> 8024545: make develop and notproduct flag values available in product builds >>> Reviewed-by: >>> >>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>> >>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>> >>> Before: >>> >>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>> Attaching to process 9399, please wait... >>> hsdb> flags -nd >>> InitialHeapSize = 495006528 5 >>> MaxHeapSize = 7920943104 5 >>> UseCompressedKlassPointers = true 5 >>> UseCompressedOops = true 5 >>> UseParallelGC = true 5 >>> hsdb> flags InlineMathNatives >>> Couldn't find flag: InlineMathNatives >>> >>> After: >>> >>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>> Attaching to process 3726, please wait... >>> hsdb> flags -nd >>> InitialHeapSize = 495006528 5 >>> MaxHeapSize = 7920943104 5 >>> UseCompressedKlassPointers = true 5 >>> UseCompressedOops = true 5 >>> UseParallelGC = true 5 >>> hsdb> flags InlineMathNatives >>> InlineMathNatives = true 0 >>> >>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>> >>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>> >>> The output for product builds is unchanged. >>> > From daniel.daugherty at oracle.com Thu Sep 12 16:30:50 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Sep 2013 17:30:50 -0600 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <52323674.6060709@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> Message-ID: <52324EAA.40806@oracle.com> On 9/12/13 3:47 PM, David Holmes wrote: > Hi Dan, > > I found a bug in the assertion related logic - new webrev: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ > > For the untimed case in park I wasn't setting the _cur_index value (I > was implicitly using zero) and so the assertion it wasn't -1 was > failing in unpark. So is the usage model for timed park() such that no other thread is calling unpark() on the thread that called timed park()? If another thread can call unpark() on a thread calling timed park(), then I think you may have a race in: 5917 assert(_cur_index != -1, "invariant"); The thread calling unpark() might reach the assertion after the thread that made the timed call to park() set: 5888 _cur_index = -1; Don't know if it's really possible, but... > With regard to assert versus assert_status - yes this would work: > > assert_status(status == 0, errno, "gettimeofday"); > > I had never considered that. :) When I added assert_status to diagnoze > a particular issue I never attempted to change all the existing > asserts on the library calls. So we have a lot of simple > "assert(status==0,"invariant") where assert_status could have been > used, as well as the old gettimeofday style calls. Do you want me to > change them all in os_linux.cpp? I guess that depends on whether we think this fix will need to be backported to HSX-24 or earlier... Less changes, the better, if a backport is in the future... Dan > > Thanks, > David > > On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: >> On 9/11/13 5:14 PM, David Holmes wrote: >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ >> >> Looks good. Possibly modulo one comment below... >> >> >>> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >>> >>>> line 5541: assert_status(status == 0, status, "clock_gettime"); >>>> line 5553: assert(status == 0, "gettimeofday"); >>>> So why is one an assert_status() call and the other is a >>>> plain old assert() call? >>> >>> Different API's. The old unix API's, like gettimeofday return -1 on >>> error and set errno. The "modern" posix APIs, eg pthread APIs and >>> clock_gettime etc, return the actual error code on error - hence >>> assert_status can be used to show the actual error in that case. >> >> I don't quite get what you're trying to say here. >> It seems that both calls are trying to verify >> that "status == 0". Or are you saying that: >> >> assert_status(status == 0, status, "gettimeofday"); >> >> is kind of a waste because "status" always be either "0" or "-1". >> So how about this: >> >> assert_status(status == 0, errno, "gettimeofday"); >> >> instead? That pattern should work to get more info. >> >> Dan >> From christian.thalinger at oracle.com Thu Sep 12 17:11:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 17:11:52 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <52324E89.9060006@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> Message-ID: On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: > Christian, > > Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? Yes, good point. > > It would be nice enumerate flag's type and use int instead of strings: > > enum { > bool_flag = 1, > intx_flag = 2, > > + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? -- Chris > > Thanks, > Vladimir > > On 9/12/13 9:58 AM, Christian Thalinger wrote: >> >> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >> >>> Hi Chris, >>> >>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>> >>> + if (is_constant_in_binary()) { >>> + fatal(err_msg("flag is constant: %s", _name)); >>> >>> into a check_writable() method so that it isn't duplicated so much. >> >> Good point. I made that change: >> >> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >> >>> >>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >> >> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >> >>> >>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >> >> The 32-bit product build also contains the server compiler. >> >> -- Chris >> >>> >>> Thanks, >>> David >>> >>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>> >>>> 8024545: make develop and notproduct flag values available in product builds >>>> Reviewed-by: >>>> >>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>> >>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>> >>>> Before: >>>> >>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>> Attaching to process 9399, please wait... >>>> hsdb> flags -nd >>>> InitialHeapSize = 495006528 5 >>>> MaxHeapSize = 7920943104 5 >>>> UseCompressedKlassPointers = true 5 >>>> UseCompressedOops = true 5 >>>> UseParallelGC = true 5 >>>> hsdb> flags InlineMathNatives >>>> Couldn't find flag: InlineMathNatives >>>> >>>> After: >>>> >>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>> Attaching to process 3726, please wait... >>>> hsdb> flags -nd >>>> InitialHeapSize = 495006528 5 >>>> MaxHeapSize = 7920943104 5 >>>> UseCompressedKlassPointers = true 5 >>>> UseCompressedOops = true 5 >>>> UseParallelGC = true 5 >>>> hsdb> flags InlineMathNatives >>>> InlineMathNatives = true 0 >>>> >>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>> >>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>> >>>> The output for product builds is unchanged. >>>> >> From serguei.spitsyn at oracle.com Thu Sep 12 17:13:43 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 17:13:43 -0700 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <52323391.3050108@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> <52323391.3050108@oracle.com> Message-ID: <523258B7.4000409@oracle.com> The updated webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ Thanks, Serguei On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote: > On 9/11/13 9:04 PM, David Holmes wrote: >> Hi Serguei, >> >> Typo: >> >> 2489 // scratch_cp is a merged constant po/ ol > > Fixed, thanks! > >> >> >> In VM_RedefineClasses::set_new_constant_pool do you not need to >> de-allocate smaller_cp if you return due to an exception here: >> >> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, >> 1, CHECK); > > Good catch. > It is better to deallocate it even if it is not very useful. > The only exception possible here is an OOME (Metadata shortage). > > > Thanks, > Serguei > >> >> David >> ----- >> >> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >>> >>> >>> >>> Summary: >>> The OOME's in the JVMTI merge_cp_and_rewrite and >>> set_new_constant_pool must be handled correctly. >>> >>> >>> Testing: >>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>> Metaspace memory, >>> nsk.jvmti.testlist, >>> nsk.jdi.testlist, >>> Jtreg java/lang/instrument >>> >>> Thanks, >>> Serguei > From coleen.phillimore at oracle.com Thu Sep 12 17:17:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 20:17:34 -0400 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <1F3F2E67-9797-41AA-BBAF-0364CAE09120@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52305A8F.3010508@oracle.com> <1F3F2E67-9797-41AA-BBAF-0364CAE09120@oracle.com> Message-ID: <5232599E.6080009@oracle.com> On 9/11/2013 12:29 PM, Christian Thalinger wrote: > On Sep 11, 2013, at 4:57 AM, Coleen Phillmore wrote: > >> Hi, >> >> Have you done performance testing on this change? When develop flags are not defined they are defined "const" false which enables the C++ compiler to do better optimizations. I've seen code that counts on that. >> If you want the values to be materialized, why not change the develop flag definition to be extern const (or some such). > develop and notproduct flags are still constants; I didn't change that. I've just put the const value in the flags table. Ok. That's fine then. I hadn't read through the code change. Coleen > > -- Chris > >> Coleen >> >> On 9/10/2013 8:56 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>> >>> 8024545: make develop and notproduct flag values available in product builds >>> Reviewed-by: >>> >>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>> >>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>> >>> Before: >>> >>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>> Attaching to process 9399, please wait... >>> hsdb> flags -nd >>> InitialHeapSize = 495006528 5 >>> MaxHeapSize = 7920943104 5 >>> UseCompressedKlassPointers = true 5 >>> UseCompressedOops = true 5 >>> UseParallelGC = true 5 >>> hsdb> flags InlineMathNatives >>> Couldn't find flag: InlineMathNatives >>> >>> After: >>> >>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>> Attaching to process 3726, please wait... >>> hsdb> flags -nd >>> InitialHeapSize = 495006528 5 >>> MaxHeapSize = 7920943104 5 >>> UseCompressedKlassPointers = true 5 >>> UseCompressedOops = true 5 >>> UseParallelGC = true 5 >>> hsdb> flags InlineMathNatives >>> InlineMathNatives = true 0 >>> >>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>> >>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>> >>> The output for product builds is unchanged. From christian.thalinger at oracle.com Thu Sep 12 17:18:18 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 17:18:18 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5232599E.6080009@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52305A8F.3010508@oracle.com> <1F3F2E67-9797-41AA-BBAF-0364CAE09120@oracle.com> <5232599E.6080009@oracle.com> Message-ID: <0159211C-426C-4112-A879-BD645E57DCF7@oracle.com> On Sep 12, 2013, at 5:17 PM, Coleen Phillmore wrote: > > On 9/11/2013 12:29 PM, Christian Thalinger wrote: >> On Sep 11, 2013, at 4:57 AM, Coleen Phillmore wrote: >> >>> Hi, >>> >>> Have you done performance testing on this change? When develop flags are not defined they are defined "const" false which enables the C++ compiler to do better optimizations. I've seen code that counts on that. >>> If you want the values to be materialized, why not change the develop flag definition to be extern const (or some such). >> develop and notproduct flags are still constants; I didn't change that. I've just put the const value in the flags table. > > Ok. That's fine then. I hadn't read through the code change. Thank you, Coleen. -- Chris > Coleen >> >> -- Chris >> >>> Coleen >>> >>> On 9/10/2013 8:56 PM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>> >>>> 8024545: make develop and notproduct flag values available in product builds >>>> Reviewed-by: >>>> >>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>> >>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>> >>>> Before: >>>> >>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>> Attaching to process 9399, please wait... >>>> hsdb> flags -nd >>>> InitialHeapSize = 495006528 5 >>>> MaxHeapSize = 7920943104 5 >>>> UseCompressedKlassPointers = true 5 >>>> UseCompressedOops = true 5 >>>> UseParallelGC = true 5 >>>> hsdb> flags InlineMathNatives >>>> Couldn't find flag: InlineMathNatives >>>> >>>> After: >>>> >>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>> Attaching to process 3726, please wait... >>>> hsdb> flags -nd >>>> InitialHeapSize = 495006528 5 >>>> MaxHeapSize = 7920943104 5 >>>> UseCompressedKlassPointers = true 5 >>>> UseCompressedOops = true 5 >>>> UseParallelGC = true 5 >>>> hsdb> flags InlineMathNatives >>>> InlineMathNatives = true 0 >>>> >>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>> >>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>> >>>> The output for product builds is unchanged. > From serguei.spitsyn at oracle.com Thu Sep 12 17:19:13 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 17:19:13 -0700 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <523258B7.4000409@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> <52323391.3050108@oracle.com> <523258B7.4000409@oracle.com> Message-ID: <52325A01.9090405@oracle.com> The update open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ Thanks, Serguei On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote: > The updated webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ > > > Thanks, > Serguei > > > On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote: >> On 9/11/13 9:04 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> Typo: >>> >>> 2489 // scratch_cp is a merged constant po/ ol >> >> Fixed, thanks! >> >>> >>> >>> In VM_RedefineClasses::set_new_constant_pool do you not need to >>> de-allocate smaller_cp if you return due to an exception here: >>> >>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, >>> 1, CHECK); >> >> Good catch. >> It is better to deallocate it even if it is not very useful. >> The only exception possible here is an OOME (Metadata shortage). >> >> >> Thanks, >> Serguei >> >>> >>> David >>> ----- >>> >>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >>>> >>>> >>>> >>>> Summary: >>>> The OOME's in the JVMTI merge_cp_and_rewrite and >>>> set_new_constant_pool must be handled correctly. >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>> Metaspace memory, >>>> nsk.jvmti.testlist, >>>> nsk.jdi.testlist, >>>> Jtreg java/lang/instrument >>>> >>>> Thanks, >>>> Serguei >> > From serguei.spitsyn at oracle.com Thu Sep 12 17:21:00 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 17:21:00 -0700 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <52321DFD.3070904@oracle.com> References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com> <52321DFD.3070904@oracle.com> Message-ID: <52325A6C.7050007@oracle.com> The updated open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/ Thanks, Serguei On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote: > On 9/11/13 9:09 PM, David Holmes wrote: >> Hi Serguei, >> >> This is more consistent with the surrounding code, but: >> >> 1. Why no RC_TRACE_WITH_THREAD for this case? > > Ok, I'll add tracing code. > >> >> 2. If an exception is pending, that isn't OOME, shouldn't "res" >> already not be JVMTI_ERROR_NONE and so res should be returned in the >> non-OOME case? > > Initially it was my concern as well. > But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL > are expected from the merge_cp_and_rewrite(). > So, it is better to keep it simple as in the webrev. > > > Thanks, > Serguei > >> >> David >> >> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 >>> >>> >>> >>> Summary: >>> Pending exceptions must be handled properly after a call to the >>> JVMTI >>> merge_cp_and_rewrite. >>> >>> >>> >>> Testing: >>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>> Metaspace memory, >>> nsk.jvmti.testlist, >>> nsk.jdi.testlist, >>> Jtreg java/lang/instrument >>> >>> Thanks, >>> Serguei >>> > From vladimir.kozlov at oracle.com Thu Sep 12 17:24:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Sep 2013 17:24:17 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> Message-ID: <52325B31.5070604@oracle.com> On 9/12/13 5:11 PM, Christian Thalinger wrote: > > On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: > >> Christian, >> >> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? > > Yes, good point. > >> >> It would be nice enumerate flag's type and use int instead of strings: >> >> enum { >> bool_flag = 1, >> intx_flag = 2, >> >> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, > > I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? Do it in separate changes after you push this. And if you remove _type field later you don't need to move _flags now. So you can push your current changes as it is. They are good. Thanks, Vladimir > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>> >>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>> >>>> Hi Chris, >>>> >>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>> >>>> + if (is_constant_in_binary()) { >>>> + fatal(err_msg("flag is constant: %s", _name)); >>>> >>>> into a check_writable() method so that it isn't duplicated so much. >>> >>> Good point. I made that change: >>> >>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>> >>>> >>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>> >>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>> >>>> >>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>> >>> The 32-bit product build also contains the server compiler. >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>> >>>>> 8024545: make develop and notproduct flag values available in product builds >>>>> Reviewed-by: >>>>> >>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>> >>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>> >>>>> Before: >>>>> >>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>> Attaching to process 9399, please wait... >>>>> hsdb> flags -nd >>>>> InitialHeapSize = 495006528 5 >>>>> MaxHeapSize = 7920943104 5 >>>>> UseCompressedKlassPointers = true 5 >>>>> UseCompressedOops = true 5 >>>>> UseParallelGC = true 5 >>>>> hsdb> flags InlineMathNatives >>>>> Couldn't find flag: InlineMathNatives >>>>> >>>>> After: >>>>> >>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>> Attaching to process 3726, please wait... >>>>> hsdb> flags -nd >>>>> InitialHeapSize = 495006528 5 >>>>> MaxHeapSize = 7920943104 5 >>>>> UseCompressedKlassPointers = true 5 >>>>> UseCompressedOops = true 5 >>>>> UseParallelGC = true 5 >>>>> hsdb> flags InlineMathNatives >>>>> InlineMathNatives = true 0 >>>>> >>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>> >>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>> >>>>> The output for product builds is unchanged. >>>>> >>> > From coleen.phillimore at oracle.com Thu Sep 12 17:47:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 20:47:17 -0400 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <52325A6C.7050007@oracle.com> References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com> <52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com> Message-ID: <52326095.8080702@oracle.com> This looks good. Coleen On 9/12/2013 8:21 PM, serguei.spitsyn at oracle.com wrote: > The updated open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/ > > > Thanks, > Serguei > > On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote: >> On 9/11/13 9:09 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> This is more consistent with the surrounding code, but: >>> >>> 1. Why no RC_TRACE_WITH_THREAD for this case? >> >> Ok, I'll add tracing code. >> >>> >>> 2. If an exception is pending, that isn't OOME, shouldn't "res" >>> already not be JVMTI_ERROR_NONE and so res should be returned in the >>> non-OOME case? >> >> Initially it was my concern as well. >> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL >> are expected from the merge_cp_and_rewrite(). >> So, it is better to keep it simple as in the webrev. >> >> >> Thanks, >> Serguei >> >>> >>> David >>> >>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 >>>> >>>> >>>> >>>> Summary: >>>> Pending exceptions must be handled properly after a call to the >>>> JVMTI >>>> merge_cp_and_rewrite. >>>> >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>> Metaspace memory, >>>> nsk.jvmti.testlist, >>>> nsk.jdi.testlist, >>>> Jtreg java/lang/instrument >>>> >>>> Thanks, >>>> Serguei >>>> >> > From serguei.spitsyn at oracle.com Thu Sep 12 17:50:52 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 17:50:52 -0700 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <52326095.8080702@oracle.com> References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com> <52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com> <52326095.8080702@oracle.com> Message-ID: <5232616C.2060400@oracle.com> Thank you, Coleen! Serguei On 9/12/13 5:47 PM, Coleen Phillmore wrote: > > This looks good. > Coleen > > On 9/12/2013 8:21 PM, serguei.spitsyn at oracle.com wrote: >> The updated open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/ >> >> >> Thanks, >> Serguei >> >> On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote: >>> On 9/11/13 9:09 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> This is more consistent with the surrounding code, but: >>>> >>>> 1. Why no RC_TRACE_WITH_THREAD for this case? >>> >>> Ok, I'll add tracing code. >>> >>>> >>>> 2. If an exception is pending, that isn't OOME, shouldn't "res" >>>> already not be JVMTI_ERROR_NONE and so res should be returned in >>>> the non-OOME case? >>> >>> Initially it was my concern as well. >>> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL >>> are expected from the merge_cp_and_rewrite(). >>> So, it is better to keep it simple as in the webrev. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> >>>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the fix for: >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 >>>>> >>>>> >>>>> >>>>> Summary: >>>>> Pending exceptions must be handled properly after a call to the >>>>> JVMTI >>>>> merge_cp_and_rewrite. >>>>> >>>>> >>>>> >>>>> Testing: >>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>> Metaspace memory, >>>>> nsk.jvmti.testlist, >>>>> nsk.jdi.testlist, >>>>> Jtreg java/lang/instrument >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>> >> > From coleen.phillimore at oracle.com Thu Sep 12 17:52:33 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 20:52:33 -0400 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <52325A01.9090405@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> <52323391.3050108@oracle.com> <523258B7.4000409@oracle.com> <52325A01.9090405@oracle.com> Message-ID: <523261D1.6000506@oracle.com> This looks good too. Thanks for catching the smaller_cp case. Coleen On 9/12/2013 8:19 PM, serguei.spitsyn at oracle.com wrote: > The update open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ > > > Thanks, > Serguei > > > On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ >> >> >> Thanks, >> Serguei >> >> >> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote: >>> On 9/11/13 9:04 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Typo: >>>> >>>> 2489 // scratch_cp is a merged constant po/ ol >>> >>> Fixed, thanks! >>> >>>> >>>> >>>> In VM_RedefineClasses::set_new_constant_pool do you not need to >>>> de-allocate smaller_cp if you return due to an exception here: >>>> >>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, >>>> 1, CHECK); >>> >>> Good catch. >>> It is better to deallocate it even if it is not very useful. >>> The only exception possible here is an OOME (Metadata shortage). >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ----- >>>> >>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >>>>> >>>>> >>>>> >>>>> Summary: >>>>> The OOME's in the JVMTI merge_cp_and_rewrite and >>>>> set_new_constant_pool must be handled correctly. >>>>> >>>>> >>>>> Testing: >>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>> Metaspace memory, >>>>> nsk.jvmti.testlist, >>>>> nsk.jdi.testlist, >>>>> Jtreg java/lang/instrument >>>>> >>>>> Thanks, >>>>> Serguei >>> >> > From serguei.spitsyn at oracle.com Thu Sep 12 17:57:05 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 17:57:05 -0700 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <523261D1.6000506@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> <52323391.3050108@oracle.com> <523258B7.4000409@oracle.com> <52325A01.9090405@oracle.com> <523261D1.6000506@oracle.com> Message-ID: <523262E1.5070609@oracle.com> Thanks! Serguei On 9/12/13 5:52 PM, Coleen Phillmore wrote: > > This looks good too. Thanks for catching the smaller_cp case. > > Coleen > > On 9/12/2013 8:19 PM, serguei.spitsyn at oracle.com wrote: >> The update open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ >> >> >> Thanks, >> Serguei >> >> >> On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote: >>>> On 9/11/13 9:04 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Typo: >>>>> >>>>> 2489 // scratch_cp is a merged constant po/ ol >>>> >>>> Fixed, thanks! >>>> >>>>> >>>>> >>>>> In VM_RedefineClasses::set_new_constant_pool do you not need to >>>>> de-allocate smaller_cp if you return due to an exception here: >>>>> >>>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, >>>>> smaller_cp, 1, CHECK); >>>> >>>> Good catch. >>>> It is better to deallocate it even if it is not very useful. >>>> The only exception possible here is an OOME (Metadata shortage). >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The OOME's in the JVMTI merge_cp_and_rewrite and >>>>>> set_new_constant_pool must be handled correctly. >>>>>> >>>>>> >>>>>> Testing: >>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>>> Metaspace memory, >>>>>> nsk.jvmti.testlist, >>>>>> nsk.jdi.testlist, >>>>>> Jtreg java/lang/instrument >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> >> > From david.holmes at oracle.com Thu Sep 12 17:59:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 10:59:22 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <52324EAA.40806@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> Message-ID: <5232636A.7070702@oracle.com> On 13/09/2013 9:30 AM, Daniel D. Daugherty wrote: > On 9/12/13 3:47 PM, David Holmes wrote: >> >> I found a bug in the assertion related logic - new webrev: >> >> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ >> >> For the untimed case in park I wasn't setting the _cur_index value (I >> was implicitly using zero) and so the assertion it wasn't -1 was >> failing in unpark. > > So is the usage model for timed park() such that no other thread > is calling unpark() on the thread that called timed park()? > > If another thread can call unpark() on a thread calling timed park(), > then I think you may have a race in: > > 5917 assert(_cur_index != -1, "invariant"); > > The thread calling unpark() might reach the assertion after the > thread that made the timed call to park() set: > > 5888 _cur_index = -1; > > Don't know if it's really possible, but... The code you refer to is all inside a critical region locked with the mutex. No races possible. >> With regard to assert versus assert_status - yes this would work: >> >> assert_status(status == 0, errno, "gettimeofday"); >> >> I had never considered that. :) When I added assert_status to diagnoze >> a particular issue I never attempted to change all the existing >> asserts on the library calls. So we have a lot of simple >> "assert(status==0,"invariant") where assert_status could have been >> used, as well as the old gettimeofday style calls. Do you want me to >> change them all in os_linux.cpp? > > I guess that depends on whether we think this fix will need to be > backported to HSX-24 or earlier... Less changes, the better, if a > backport is in the future... Yes backports to 7 and 6 are definitely on the cards. The assert/assert_status can be cleaned up as part of the big cleanup for 9 (where a lot of the calls will disappear anyway as we get rid of all the ancient workarounds). So I will leave this aspect as is. Thanks, David > Dan > > >> >> Thanks, >> David >> >> On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: >>> On 9/11/13 5:14 PM, David Holmes wrote: >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ >>> >>> Looks good. Possibly modulo one comment below... >>> >>> >>>> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >>>> >>>>> line 5541: assert_status(status == 0, status, "clock_gettime"); >>>>> line 5553: assert(status == 0, "gettimeofday"); >>>>> So why is one an assert_status() call and the other is a >>>>> plain old assert() call? >>>> >>>> Different API's. The old unix API's, like gettimeofday return -1 on >>>> error and set errno. The "modern" posix APIs, eg pthread APIs and >>>> clock_gettime etc, return the actual error code on error - hence >>>> assert_status can be used to show the actual error in that case. >>> >>> I don't quite get what you're trying to say here. >>> It seems that both calls are trying to verify >>> that "status == 0". Or are you saying that: >>> >>> assert_status(status == 0, status, "gettimeofday"); >>> >>> is kind of a waste because "status" always be either "0" or "-1". >>> So how about this: >>> >>> assert_status(status == 0, errno, "gettimeofday"); >>> >>> instead? That pattern should work to get more info. >>> >>> Dan >>> > From christian.thalinger at oracle.com Thu Sep 12 18:00:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 18:00:58 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <52325B31.5070604@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> Message-ID: <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: > On 9/12/13 5:11 PM, Christian Thalinger wrote: >> >> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >> >>> Christian, >>> >>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >> >> Yes, good point. >> >>> >>> It would be nice enumerate flag's type and use int instead of strings: >>> >>> enum { >>> bool_flag = 1, >>> intx_flag = 2, >>> >>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >> >> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? > > Do it in separate changes after you push this. > And if you remove _type field later you don't need to move _flags now. > So you can push your current changes as it is. They are good. Thank you, Vladimir. -- Chris > > Thanks, > Vladimir > >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>> >>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>> >>>>> + if (is_constant_in_binary()) { >>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>> >>>>> into a check_writable() method so that it isn't duplicated so much. >>>> >>>> Good point. I made that change: >>>> >>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>> >>>>> >>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>> >>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>> >>>>> >>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>> >>>> The 32-bit product build also contains the server compiler. >>>> >>>> -- Chris >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>> >>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>> Reviewed-by: >>>>>> >>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>> >>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>> >>>>>> Before: >>>>>> >>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>> Attaching to process 9399, please wait... >>>>>> hsdb> flags -nd >>>>>> InitialHeapSize = 495006528 5 >>>>>> MaxHeapSize = 7920943104 5 >>>>>> UseCompressedKlassPointers = true 5 >>>>>> UseCompressedOops = true 5 >>>>>> UseParallelGC = true 5 >>>>>> hsdb> flags InlineMathNatives >>>>>> Couldn't find flag: InlineMathNatives >>>>>> >>>>>> After: >>>>>> >>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>> Attaching to process 3726, please wait... >>>>>> hsdb> flags -nd >>>>>> InitialHeapSize = 495006528 5 >>>>>> MaxHeapSize = 7920943104 5 >>>>>> UseCompressedKlassPointers = true 5 >>>>>> UseCompressedOops = true 5 >>>>>> UseParallelGC = true 5 >>>>>> hsdb> flags InlineMathNatives >>>>>> InlineMathNatives = true 0 >>>>>> >>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>> >>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>> >>>>>> The output for product builds is unchanged. >>>>>> >>>> >> From christian.thalinger at oracle.com Thu Sep 12 18:06:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 18:06:58 -0700 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs Message-ID: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> http://cr.openjdk.java.net/~twisti/8024760/webrev/ 8024760: add more types, fields and constants to VMStructs Reviewed-by: Some types, fields and constants we need to investigate bugs. There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java src/share/vm/gc_implementation/g1/ptrQueue.hpp src/share/vm/memory/universe.cpp src/share/vm/memory/universe.hpp src/share/vm/oops/klassVtable.hpp src/share/vm/oops/methodData.hpp src/share/vm/runtime/os.hpp src/share/vm/runtime/vmStructs.cpp From coleen.phillimore at oracle.com Thu Sep 12 18:10:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 21:10:39 -0400 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52321447.4000405@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> Message-ID: <5232660F.1050701@oracle.com> It took me a while to remember why this change is the way it is. Why do you clear the pending exception at line 1601? thanks, Coleen On 9/12/2013 3:21 PM, serguei.spitsyn at oracle.com wrote: > On 9/11/13 8:54 PM, David Holmes wrote: >> Hi Dmitry, >> >> It seems odd that you install the new_method even if there was an >> exception. What if the new_method is not valid because of the >> exception ? > > Coleen suggested this fragment. > New methods will be deallocated with the scratch class in a case of > exception. > It is handled in the doit_prologue where the scratch classes are added > to the CL deallocation list. > >> >> Also once you've cleared the exception and returned false, the user >> has no information as to why this failed. I understand we don't want >> to hit the guarantee here, but it seems there is a hole in the error >> flow. > > This issue is fixed in a separate bug fix for 8024346 (see another > review request). > Sorry for the confusion here. > > The whole error flow is not perfect but I'm not targetting to make it > perfect now. > Multiple bugs on the limited Metaspace topic were filed by Stefan: > 8017230, 8024345, 8024346. > My role is to apply/test fixes suggested by Stefan and Coleen in the > order the issues were discovered. > > > Thanks, > Serguei > >> >> David >> >> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>> >>> >>> Summary: >>> Handle pending exceptions instead of firing a guarantee() in the >>> JVMTI rewrite_cp_refs_in_method(). >>> >>> >>> Testing: >>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>> Metaspace memory, >>> nsk.jvmti.testlist, >>> nsk.jdi.testlist, >>> Jtreg java/lang/instrument >>> >>> Thanks, >>> Serguei > From vladimir.kozlov at oracle.com Thu Sep 12 18:19:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Sep 2013 18:19:36 -0700 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs In-Reply-To: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> References: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> Message-ID: <52326828.7030609@oracle.com> Good. Vladimir On 9/12/13 6:06 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8024760/webrev/ > > 8024760: add more types, fields and constants to VMStructs > Reviewed-by: > > Some types, fields and constants we need to investigate bugs. > > There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. > > agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java > src/share/vm/gc_implementation/g1/ptrQueue.hpp > src/share/vm/memory/universe.cpp > src/share/vm/memory/universe.hpp > src/share/vm/oops/klassVtable.hpp > src/share/vm/oops/methodData.hpp > src/share/vm/runtime/os.hpp > src/share/vm/runtime/vmStructs.cpp > From coleen.phillimore at oracle.com Thu Sep 12 18:22:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 21:22:06 -0400 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52321F30.9030102@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> <52321CE2.9020307@oracle.com> <52321F30.9030102@oracle.com> Message-ID: <523268BE.7030902@oracle.com> I see the answer to my question in the mail that hasn't come out yet. The error handling in this code relies on boolean returns in order to throw a JVMTI_ERROR code. Maybe a comment to this effect would be good above CLEAR_PENDING_EXCEPTION. I don't need to rereview this. > Yes, of course. > It is my resp. to double-check and make it final. Yes and thank you for doing the extra work to verify that the changes that we made weren't just workarounds and are correct and tested. The error handling here isn't very robust but that would require some redesign to make it so. Thanks, Coleen > But you deserved the credit for this investigation anyway. :) > > Thanks, > Serguei > >> >> thanks, >> StefanK >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> >>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>>>> >>>>> >>>>> Summary: >>>>> Handle pending exceptions instead of firing a guarantee() in the >>>>> JVMTI rewrite_cp_refs_in_method(). >>>>> >>>>> >>>>> Testing: >>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>> Metaspace memory, >>>>> nsk.jvmti.testlist, >>>>> nsk.jdi.testlist, >>>>> Jtreg java/lang/instrument >>>>> >>>>> Thanks, >>>>> Serguei >>> >> > From coleen.phillimore at oracle.com Thu Sep 12 18:30:41 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 21:30:41 -0400 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs In-Reply-To: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> References: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> Message-ID: <52326AC1.8000603@oracle.com> This looks ok. Coleen On 9/12/2013 9:06 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8024760/webrev/ > > 8024760: add more types, fields and constants to VMStructs > Reviewed-by: > > Some types, fields and constants we need to investigate bugs. > > There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. > > agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java > src/share/vm/gc_implementation/g1/ptrQueue.hpp > src/share/vm/memory/universe.cpp > src/share/vm/memory/universe.hpp > src/share/vm/oops/klassVtable.hpp > src/share/vm/oops/methodData.hpp > src/share/vm/runtime/os.hpp > src/share/vm/runtime/vmStructs.cpp > From 76069016 at qq.com Thu Sep 12 18:49:34 2013 From: 76069016 at qq.com (=?gb18030?B?SXNtbA==?=) Date: Fri, 13 Sep 2013 09:49:34 +0800 Subject: =?gb18030?B?u9i4tKO6IElzIGl0IHBvc3NpYmxlIHRvIHN0YXRp?= =?gb18030?B?YyBsaW5rIGp2bT8=?= In-Reply-To: <3114BC45-D10F-4CE3-9AA4-F6AF1DBC75D3@oracle.com> References: <3114BC45-D10F-4CE3-9AA4-F6AF1DBC75D3@oracle.com> Message-ID: OK, I got it. Thanks for your reply! ------------------ ???????? ------------------ ??????: "Bob Vandette"; ????????: 2013??9??12??(??????) ????11:43 ??????: "Isml"<76069016 at qq.com>; ????: "hotspot-dev"; ????: Re: Is it possible to static link jvm? The hotspot sources do not currently support statically linking. There are a number of places in the hotspot sources that would have to be modified in order to support this. It is only in JDK 8 that we modified the JNI and JVMTI specifications to allow statically linked JNI libraries. This is the first step in allowing a completely statically linked VM and Java runtime. Bob. On Sep 12, 2013, at 5:17 AM, Isml wrote: > Hi, everyone! > I am reading launcher code(hotspot7u\src\share\tools\launcher etc.) in the hotspot project and see some comments like this(in file hotspot7u\src\os\windows\launcher\java_md.c, line 434): > > jboolean > LoadJavaVM(const char *jvmpath, InvocationFunctions *ifn) > { > #ifdef GAMMA > /* JVM is directly linked with gamma launcher; no Loadlibrary() */ > ifn->CreateJavaVM = JNI_CreateJavaVM; > ifn->GetDefaultJavaVMInitArgs = JNI_GetDefaultJavaVMInitArgs; > return JNI_TRUE; > #else > > It seems that jvm could be staticly linked. So I just do some try. After some tiny modifications, I successfully compiled it and link the jvm. But when I run it, it fails with error "unable to find jvm.dll". I debug the code, and find the actual reason why it failes(src\share\vm\runtime\os.cpp, line 385): > > void* os::native_java_library() { > dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "verify"); > dll_load(buffer, ebuf, sizeof(ebuf)); > // Load java dll > dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "java"); > _native_java_library = dll_load(buffer, ebuf, sizeof(ebuf)); > > verify.dll and java.dll is designed to be load here, and they all depends on jvm.dll! > Now I do not how to do, any idea? . From coleen.phillimore at oracle.com Thu Sep 12 19:04:54 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 22:04:54 -0400 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data In-Reply-To: <20130912214601.GC4100@ehelin-thinkpad> References: <20130912214601.GC4100@ehelin-thinkpad> Message-ID: <523272C6.5000806@oracle.com> Erik, This change looks really good. They all call the same functions in MetaspaceAux (we should come up with a better name for this class). Thanks! Coleen On 9/12/2013 5:46 PM, Erik Helin wrote: > Hi all, > > this patch fixes some issues with memory pools and the performance > counter reporting slightly different numbers for metaspace. I've also > updated two jtreg tests as well as added a new one to test the change. > > InputArguments.java in the testlibrary is updated as well. > InputArguments.contains now takes a prefix as a parameter instead of the > exact name of a flag. This makes it possible to check if a flag expecting > a value has been set. For example, -XX:MaxMetaspaceSize=100m can be > checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ > > Testing: > - JPRT > - hotspot/test/gc (including updated and new tests) > > Thanks, > Erik From christian.thalinger at oracle.com Thu Sep 12 19:29:47 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 19:29:47 -0700 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs In-Reply-To: <52326828.7030609@oracle.com> References: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> <52326828.7030609@oracle.com> Message-ID: <4D241E5E-B526-4BAB-9E3A-A770C91C20A1@oracle.com> Thank you, Vladimir. -- Chris On Sep 12, 2013, at 6:19 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 9/12/13 6:06 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8024760/webrev/ >> >> 8024760: add more types, fields and constants to VMStructs >> Reviewed-by: >> >> Some types, fields and constants we need to investigate bugs. >> >> There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. >> >> agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >> src/share/vm/gc_implementation/g1/ptrQueue.hpp >> src/share/vm/memory/universe.cpp >> src/share/vm/memory/universe.hpp >> src/share/vm/oops/klassVtable.hpp >> src/share/vm/oops/methodData.hpp >> src/share/vm/runtime/os.hpp >> src/share/vm/runtime/vmStructs.cpp >> From christian.thalinger at oracle.com Thu Sep 12 19:29:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Sep 2013 19:29:59 -0700 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs In-Reply-To: <52326AC1.8000603@oracle.com> References: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> <52326AC1.8000603@oracle.com> Message-ID: Thank you, Coleen. -- Chris On Sep 12, 2013, at 6:30 PM, Coleen Phillmore wrote: > > This looks ok. > Coleen > > On 9/12/2013 9:06 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8024760/webrev/ >> >> 8024760: add more types, fields and constants to VMStructs >> Reviewed-by: >> >> Some types, fields and constants we need to investigate bugs. >> >> There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. >> >> agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >> src/share/vm/gc_implementation/g1/ptrQueue.hpp >> src/share/vm/memory/universe.cpp >> src/share/vm/memory/universe.hpp >> src/share/vm/oops/klassVtable.hpp >> src/share/vm/oops/methodData.hpp >> src/share/vm/runtime/os.hpp >> src/share/vm/runtime/vmStructs.cpp >> > From coleen.phillimore at oracle.com Thu Sep 12 19:35:52 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 12 Sep 2013 22:35:52 -0400 Subject: RFR: 8024505 [TESTBUG] update test groups for additional tests that can't run on the minimal VM In-Reply-To: <522FF5E6.7030407@oracle.com> References: <522FF5E6.7030407@oracle.com> Message-ID: <52327A08.6070801@oracle.com> David, Looks good. Coleen On 9/11/2013 12:47 AM, David Holmes wrote: > The initial definition of the groups that need a full VM missed some of > the tests that exec a second VM without passing on the VM selection > flag. i.e we run jtreg with -vmoption:-minimal but the test then runs > "java -XX:.. ,args>" and relies on jvm.cfg to select the default VM - > which will not be the minimal VM unless in a JRE where only the minimal > VM is present. Hence the test incorrectly passes. > > webrev: > > http://cr.openjdk.java.net/~dholmes/8024505/webrev/ > > I also fixed XCheckJSig as it can only run on a full JDK. > > Pushing through hotspot-emb. > > Thanks, > David From david.holmes at oracle.com Thu Sep 12 20:23:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 13:23:07 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5232636A.7070702@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> Message-ID: <5232851B.3000103@oracle.com> Still not right. I confused the PlatformEvent logic with the Parker logic and thought that the check "s < 1" indicated a thread was definitely blocked; but it doesn't it only means that a thread may be blocked. Hence if the thread is not blocked _cur_index == -1 and the assert trips. So remove the assert and add a check for _cur_index != -1, as that means a thread is definitely blocked. Updated webrev: http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ but testing still TBD so hold off on further reviews. The logic is messy now with yet-another mutex-unlock having to be added, but I wanted to minimize the potential change - let me know if you think it worthwhile refactoring. Thanks, David On 13/09/2013 10:59 AM, David Holmes wrote: > On 13/09/2013 9:30 AM, Daniel D. Daugherty wrote: >> On 9/12/13 3:47 PM, David Holmes wrote: >>> >>> I found a bug in the assertion related logic - new webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ >>> >>> For the untimed case in park I wasn't setting the _cur_index value (I >>> was implicitly using zero) and so the assertion it wasn't -1 was >>> failing in unpark. >> >> So is the usage model for timed park() such that no other thread >> is calling unpark() on the thread that called timed park()? >> >> If another thread can call unpark() on a thread calling timed park(), >> then I think you may have a race in: >> >> 5917 assert(_cur_index != -1, "invariant"); >> >> The thread calling unpark() might reach the assertion after the >> thread that made the timed call to park() set: >> >> 5888 _cur_index = -1; >> >> Don't know if it's really possible, but... > > The code you refer to is all inside a critical region locked with the > mutex. No races possible. > > >>> With regard to assert versus assert_status - yes this would work: >>> >>> assert_status(status == 0, errno, "gettimeofday"); >>> >>> I had never considered that. :) When I added assert_status to diagnoze >>> a particular issue I never attempted to change all the existing >>> asserts on the library calls. So we have a lot of simple >>> "assert(status==0,"invariant") where assert_status could have been >>> used, as well as the old gettimeofday style calls. Do you want me to >>> change them all in os_linux.cpp? >> >> I guess that depends on whether we think this fix will need to be >> backported to HSX-24 or earlier... Less changes, the better, if a >> backport is in the future... > > Yes backports to 7 and 6 are definitely on the cards. The > assert/assert_status can be cleaned up as part of the big cleanup for 9 > (where a lot of the calls will disappear anyway as we get rid of all the > ancient workarounds). So I will leave this aspect as is. > > Thanks, > David > >> Dan >> >> >>> >>> Thanks, >>> David >>> >>> On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: >>>> On 9/11/13 5:14 PM, David Holmes wrote: >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ >>>> >>>> Looks good. Possibly modulo one comment below... >>>> >>>> >>>>> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >>>>> >>>>>> line 5541: assert_status(status == 0, status, "clock_gettime"); >>>>>> line 5553: assert(status == 0, "gettimeofday"); >>>>>> So why is one an assert_status() call and the other is a >>>>>> plain old assert() call? >>>>> >>>>> Different API's. The old unix API's, like gettimeofday return -1 on >>>>> error and set errno. The "modern" posix APIs, eg pthread APIs and >>>>> clock_gettime etc, return the actual error code on error - hence >>>>> assert_status can be used to show the actual error in that case. >>>> >>>> I don't quite get what you're trying to say here. >>>> It seems that both calls are trying to verify >>>> that "status == 0". Or are you saying that: >>>> >>>> assert_status(status == 0, status, "gettimeofday"); >>>> >>>> is kind of a waste because "status" always be either "0" or "-1". >>>> So how about this: >>>> >>>> assert_status(status == 0, errno, "gettimeofday"); >>>> >>>> instead? That pattern should work to get more info. >>>> >>>> Dan >>>> >> From serguei.spitsyn at oracle.com Thu Sep 12 20:45:26 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 20:45:26 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <523268BE.7030902@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> <52321CE2.9020307@oracle.com> <52321F30.9030102@oracle.com> <523268BE.7030902@oracle.com> Message-ID: <52328A56.7050003@oracle.com> On 9/12/13 6:22 PM, Coleen Phillmore wrote: > > I see the answer to my question in the mail that hasn't come out > yet. The error handling in this code relies on boolean returns in > order to throw a JVMTI_ERROR code. Maybe a comment to this effect > would be good above CLEAR_PENDING_EXCEPTION. I don't need to > rereview this. temporary patches to get me past the bugs, not final fixes. Ok, I will add a comment to this line to make it more clear. > > < >> >> Yes, of course. >> It is my resp. to double-check and make it final. > > Yes and thank you for doing the extra work to verify that the changes > that we made weren't just workarounds and are correct and tested. > The error handling here isn't very robust but that would require some > redesign to make it so. Thank you for the review! Serguei > > Thanks, > Coleen > >> But you deserved the credit for this investigation anyway. :) >> >> Thanks, >> Serguei >> >>> >>> thanks, >>> StefanK >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> >>>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>>>>> >>>>>> >>>>>> Summary: >>>>>> Handle pending exceptions instead of firing a guarantee() in the >>>>>> JVMTI rewrite_cp_refs_in_method(). >>>>>> >>>>>> >>>>>> Testing: >>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>>> Metaspace memory, >>>>>> nsk.jvmti.testlist, >>>>>> nsk.jdi.testlist, >>>>>> Jtreg java/lang/instrument >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Sep 12 21:17:48 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Sep 2013 21:17:48 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <5232660F.1050701@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> <5232660F.1050701@oracle.com> Message-ID: <523291EC.3070007@oracle.com> I believe, you found the answer to this in your next email. Thanks, Serguei On 9/12/13 6:10 PM, Coleen Phillmore wrote: > > It took me a while to remember why this change is the way it is. Why > do you clear the pending exception at line 1601? > thanks, > Coleen > > On 9/12/2013 3:21 PM, serguei.spitsyn at oracle.com wrote: >> On 9/11/13 8:54 PM, David Holmes wrote: >>> Hi Dmitry, >>> >>> It seems odd that you install the new_method even if there was an >>> exception. What if the new_method is not valid because of the >>> exception ? >> >> Coleen suggested this fragment. >> New methods will be deallocated with the scratch class in a case of >> exception. >> It is handled in the doit_prologue where the scratch classes are >> added to the CL deallocation list. >> >>> >>> Also once you've cleared the exception and returned false, the user >>> has no information as to why this failed. I understand we don't want >>> to hit the guarantee here, but it seems there is a hole in the error >>> flow. >> >> This issue is fixed in a separate bug fix for 8024346 (see another >> review request). >> Sorry for the confusion here. >> >> The whole error flow is not perfect but I'm not targetting to make it >> perfect now. >> Multiple bugs on the limited Metaspace topic were filed by Stefan: >> 8017230, 8024345, 8024346. >> My role is to apply/test fixes suggested by Stefan and Coleen in the >> order the issues were discovered. >> >> >> Thanks, >> Serguei >> >>> >>> David >>> >>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>>> >>>> >>>> Summary: >>>> Handle pending exceptions instead of firing a guarantee() in the >>>> JVMTI rewrite_cp_refs_in_method(). >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>> Metaspace memory, >>>> nsk.jvmti.testlist, >>>> nsk.jdi.testlist, >>>> Jtreg java/lang/instrument >>>> >>>> Thanks, >>>> Serguei >> > From bengt.rutisson at oracle.com Thu Sep 12 23:04:09 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 13 Sep 2013 08:04:09 +0200 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <52322284.4000601@oracle.com> References: <523221AB.6040103@oracle.com> <52322284.4000601@oracle.com> Message-ID: <5232AAD9.1070909@oracle.com> Stefan, Looks good. Bengt On 9/12/13 10:22 PM, Stefan Karlsson wrote: > Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this > change code that are shared between different HotSpot sub-components. > > StefanK > > -------- Original Message -------- > Subject: Review request: 8024752: Log TraceMetadata* output to > gclog_or_tty instead of tty > Date: Thu, 12 Sep 2013 22:18:51 +0200 > From: Stefan Karlsson > To: hotspot-gc-dev at openjdk.java.net > > > > http://cr.openjdk.java.net/~stefank/8024752/webrev.00 > > The output you get when turning on the TraceMetadata* flags end up in > different files. This makes these flags hard to use. > > The patch directs the output to the gclog_or_tty output stream. > > thanks, > StefanK > > > From stefan.karlsson at oracle.com Thu Sep 12 23:05:55 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Sep 2013 08:05:55 +0200 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <5232AAD9.1070909@oracle.com> References: <523221AB.6040103@oracle.com> <52322284.4000601@oracle.com> <5232AAD9.1070909@oracle.com> Message-ID: <5232AB43.1060100@oracle.com> On 9/13/13 8:04 AM, Bengt Rutisson wrote: > > Stefan, > > Looks good. Thanks, Bengt. StefanK > > Bengt > > On 9/12/13 10:22 PM, Stefan Karlsson wrote: >> Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this >> change code that are shared between different HotSpot sub-components. >> >> StefanK >> >> -------- Original Message -------- >> Subject: Review request: 8024752: Log TraceMetadata* output to >> gclog_or_tty instead of tty >> Date: Thu, 12 Sep 2013 22:18:51 +0200 >> From: Stefan Karlsson >> To: hotspot-gc-dev at openjdk.java.net >> >> >> >> >> http://cr.openjdk.java.net/~stefank/8024752/webrev.00 >> >> The output you get when turning on the TraceMetadata* flags end up in >> different files. This makes these flags hard to use. >> >> The patch directs the output to the gclog_or_tty output stream. >> >> thanks, >> StefanK >> >> >> > From mikael.gerdin at oracle.com Fri Sep 13 01:25:54 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 13 Sep 2013 10:25:54 +0200 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <52322284.4000601@oracle.com> References: <523221AB.6040103@oracle.com> <52322284.4000601@oracle.com> Message-ID: <5232CC12.9050103@oracle.com> Stefan, On 2013-09-12 22:22, Stefan Karlsson wrote: > Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this change > code that are shared between different HotSpot sub-components. > > StefanK > > -------- Original Message -------- > Subject: Review request: 8024752: Log TraceMetadata* output to > gclog_or_tty instead of tty > Date: Thu, 12 Sep 2013 22:18:51 +0200 > From: Stefan Karlsson > To: hotspot-gc-dev at openjdk.java.net > > > > http://cr.openjdk.java.net/~stefank/8024752/webrev.00 The change looks good. /Mikael > > The output you get when turning on the TraceMetadata* flags end up in > different files. This makes these flags hard to use. > > The patch directs the output to the gclog_or_tty output stream. > > thanks, > StefanK > > From stefan.karlsson at oracle.com Fri Sep 13 01:30:06 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Sep 2013 10:30:06 +0200 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <5232CC12.9050103@oracle.com> References: <523221AB.6040103@oracle.com> <52322284.4000601@oracle.com> <5232CC12.9050103@oracle.com> Message-ID: <5232CD0E.4070202@oracle.com> On 09/13/2013 10:25 AM, Mikael Gerdin wrote: > Stefan, > > On 2013-09-12 22:22, Stefan Karlsson wrote: >> Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this change >> code that are shared between different HotSpot sub-components. >> >> StefanK >> >> -------- Original Message -------- >> Subject: Review request: 8024752: Log TraceMetadata* output to >> gclog_or_tty instead of tty >> Date: Thu, 12 Sep 2013 22:18:51 +0200 >> From: Stefan Karlsson >> To: hotspot-gc-dev at openjdk.java.net >> >> >> >> >> http://cr.openjdk.java.net/~stefank/8024752/webrev.00 > > The change looks good. Thanks, Mikael. StefanK > > /Mikael > >> >> The output you get when turning on the TraceMetadata* flags end up in >> different files. This makes these flags hard to use. >> >> The patch directs the output to the gclog_or_tty output stream. >> >> thanks, >> StefanK >> >> From bengt.rutisson at oracle.com Fri Sep 13 01:58:37 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 13 Sep 2013 10:58:37 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5231DB36.6080101@oracle.com> References: <5231DB36.6080101@oracle.com> Message-ID: <5232D3BD.40907@oracle.com> Hi Stefan, On 9/12/13 5:18 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ > > - Limit MetaspaceSize to MaxMetaspaceSize > - Make sure we don't align down to 0. > - jtreg test > > Note that this patch also adds/changes some functionality in the > OutputAnalyzer in test/testlibrary. > > thanks, > StefanK One minor thing is that I think we could remove this line in collectorPolicy.cpp: 72 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { Doing that will make sure that we always have MetaspaceSize <= MaxMetaspaceSize, which I think is the case already in the code, but this would make it clearer. About the test. Instead of parsing the PrintFlagsFinal output you could use ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(" MaxMetaspaceSize") etc. There are some other tests that to this. For example: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/file/9561e0a8a2d6/test/gc/arguments/TestG1HeapRegionSize.java A question about the new firstMatch() method in OutputAnalyzer. Is it more natural to first check stderr or stdout? Thanks, Bengt From thomas.schatzl at oracle.com Fri Sep 13 02:21:17 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 Sep 2013 11:21:17 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5232D3BD.40907@oracle.com> References: <5231DB36.6080101@oracle.com> <5232D3BD.40907@oracle.com> Message-ID: <1379064077.3040.12.camel@cirrus> Hi, On Fri, 2013-09-13 at 10:58 +0200, Bengt Rutisson wrote: > Hi Stefan, > > On 9/12/13 5:18 PM, Stefan Karlsson wrote: > > http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ > > > > - Limit MetaspaceSize to MaxMetaspaceSize > > - Make sure we don't align down to 0. > > - jtreg test > > > > Note that this patch also adds/changes some functionality in the > > OutputAnalyzer in test/testlibrary. > > > > thanks, > > StefanK > > One minor thing is that I think we could remove this line in > collectorPolicy.cpp: > > 72 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { > > Doing that will make sure that we always have MetaspaceSize <= > MaxMetaspaceSize, which I think is the case already in the code, but > this would make it clearer. Actually I think it is required to be removed. What if you set only MetaspaceSize to some value above MaxMetaspaceSize? Maybe a some assert at the end of the method that verifies this requirement should be added, e.g. assert(MetaspaceSize <= MaxMetaspaceSize, ...) > About the test. Instead of parsing the PrintFlagsFinal output you could > use ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(" > MaxMetaspaceSize") etc. If I am not mistaken, the test starts another VM and wants to check the values of the other VM. The method you proposed gets the values of the current VM only. The test is also missing subtests when not setting MetaspaceSize/MaxMetaspaceSize at all. I.e. it does not stress any code using FLAG_IS_DEFAULT, if I read it correctly. To determine the "conservative" max heap alignment the change could add a whitebox method providing it - the code has just been checked in - instead of defining it as a constant. You add -XX:-UseLargePages to the command line though. There are also no (eventually failing) tests for boundaries, i.e. setting any of the variables to zero or max_uintx. Thomas From thomas.schatzl at oracle.com Fri Sep 13 02:27:46 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 Sep 2013 11:27:46 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5231DB36.6080101@oracle.com> References: <5231DB36.6080101@oracle.com> Message-ID: <1379064466.3040.15.camel@cirrus> Hi Stefan, On Thu, 2013-09-12 at 17:18 +0200, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ > > - Limit MetaspaceSize to MaxMetaspaceSize > - Make sure we don't align down to 0. > - jtreg test > > Note that this patch also adds/changes some functionality in the > OutputAnalyzer in test/testlibrary. I have some question about this code: 90 if (MetaspaceSize < 256*K) { 91 vm_exit_during_initialization("Too small initial Metaspace size"); 92 } can this code still be hit, given that you always round up MetaspaceSize to min_alignment(). It sounds more logical to test MaxMetaspaceSize for that amount - and maybe even set (Max)MetaspaceSize to this value at minimum. The code already does the changes due to alignment anyway. Just a thought. Thomas From stefan.karlsson at oracle.com Fri Sep 13 02:31:22 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Sep 2013 11:31:22 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5232D3BD.40907@oracle.com> References: <5231DB36.6080101@oracle.com> <5232D3BD.40907@oracle.com> Message-ID: <5232DB6A.3030202@oracle.com> On 09/13/2013 10:58 AM, Bengt Rutisson wrote: > > Hi Stefan, > > On 9/12/13 5:18 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ >> >> - Limit MetaspaceSize to MaxMetaspaceSize >> - Make sure we don't align down to 0. >> - jtreg test >> >> Note that this patch also adds/changes some functionality in the >> OutputAnalyzer in test/testlibrary. >> >> thanks, >> StefanK > > One minor thing is that I think we could remove this line in > collectorPolicy.cpp: > > 72 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { > > Doing that will make sure that we always have MetaspaceSize <= > MaxMetaspaceSize, which I think is the case already in the code, but > this would make it clearer. Will do. > > > About the test. Instead of parsing the PrintFlagsFinal output you > could use ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(" > MaxMetaspaceSize") etc. There are some other tests that to this. For > example: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/file/9561e0a8a2d6/test/gc/arguments/TestG1HeapRegionSize.java > > > A question about the new firstMatch() method in OutputAnalyzer. Is it > more natural to first check stderr or stdout? I'll try your approach and remove the firstMatch. thanks, StefanK > > Thanks, > Bengt > > > > From stefan.karlsson at oracle.com Fri Sep 13 02:39:21 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Sep 2013 11:39:21 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <1379064077.3040.12.camel@cirrus> References: <5231DB36.6080101@oracle.com> <5232D3BD.40907@oracle.com> <1379064077.3040.12.camel@cirrus> Message-ID: <5232DD49.2010005@oracle.com> On 09/13/2013 11:21 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2013-09-13 at 10:58 +0200, Bengt Rutisson wrote: >> Hi Stefan, >> >> On 9/12/13 5:18 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ >>> >>> - Limit MetaspaceSize to MaxMetaspaceSize >>> - Make sure we don't align down to 0. >>> - jtreg test >>> >>> Note that this patch also adds/changes some functionality in the >>> OutputAnalyzer in test/testlibrary. >>> >>> thanks, >>> StefanK >> One minor thing is that I think we could remove this line in >> collectorPolicy.cpp: >> >> 72 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >> >> Doing that will make sure that we always have MetaspaceSize <= >> MaxMetaspaceSize, which I think is the case already in the code, but >> this would make it clearer. > Actually I think it is required to be removed. > > What if you set only MetaspaceSize to some value above MaxMetaspaceSize? > > Maybe a some assert at the end of the method that verifies this > requirement should be added, e.g. I'll remove it. > > assert(MetaspaceSize <= MaxMetaspaceSize, ...) I'll add it. > >> About the test. Instead of parsing the PrintFlagsFinal output you could >> use ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(" >> MaxMetaspaceSize") etc. > If I am not mistaken, the test starts another VM and wants to check the > values of the other VM. > > The method you proposed gets the values of the current VM only. Good point. Are you OK with me using my current approach then? > > The test is also missing subtests when not setting > MetaspaceSize/MaxMetaspaceSize at all. I.e. it does not stress any code > using FLAG_IS_DEFAULT, if I read it correctly. I'm going to remove the FLAG_IS_DEFUALT check. > > To determine the "conservative" max heap alignment the change could add > a whitebox method providing it - the code has just been checked in - > instead of defining it as a constant. You add -XX:-UseLargePages to the > command line though. Yeah. I don't want to spend ages writing this test. If we get a problem with this, we'll fix it then. > > There are also no (eventually failing) tests for boundaries, i.e. > setting any of the variables to zero or max_uintx. I can add one where I set the flags to 0. thanks, StefanK > > Thomas > From erik.helin at oracle.com Fri Sep 13 02:59:57 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 13 Sep 2013 11:59:57 +0200 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data In-Reply-To: <523272C6.5000806@oracle.com> References: <20130912214601.GC4100@ehelin-thinkpad> <523272C6.5000806@oracle.com> Message-ID: <20130913095957.GA2102@ehelin-thinkpad> Hi Coleen, thanks for the review! Erik On 2013-09-12, Coleen Phillmore wrote: > > Erik, > This change looks really good. They all call the same functions in > MetaspaceAux (we should come up with a better name for this class). > Thanks! > Coleen > > On 9/12/2013 5:46 PM, Erik Helin wrote: > >Hi all, > > > >this patch fixes some issues with memory pools and the performance > >counter reporting slightly different numbers for metaspace. I've also > >updated two jtreg tests as well as added a new one to test the change. > > > >InputArguments.java in the testlibrary is updated as well. > >InputArguments.contains now takes a prefix as a parameter instead of the > >exact name of a flag. This makes it possible to check if a flag expecting > >a value has been set. For example, -XX:MaxMetaspaceSize=100m can be > >checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ > > > >Testing: > >- JPRT > >- hotspot/test/gc (including updated and new tests) > > > >Thanks, > >Erik > From david.holmes at oracle.com Fri Sep 13 04:07:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 21:07:28 +1000 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data In-Reply-To: <20130912214601.GC4100@ehelin-thinkpad> References: <20130912214601.GC4100@ehelin-thinkpad> Message-ID: <5232F1F0.3090302@oracle.com> Hi Erik, Just looking at the tests ... Can you please add -XX:+UsePerfData to the @run lines of the new test. Have you discussed the change to InputArguments.contains? If we have any args that are substrings of other args then this change will cause incorrect matching. Would it not be better to add a new function that checks the prefix rather than the whole arg? Thanks, David On 13/09/2013 7:46 AM, Erik Helin wrote: > Hi all, > > this patch fixes some issues with memory pools and the performance > counter reporting slightly different numbers for metaspace. I've also > updated two jtreg tests as well as added a new one to test the change. > > InputArguments.java in the testlibrary is updated as well. > InputArguments.contains now takes a prefix as a parameter instead of the > exact name of a flag. This makes it possible to check if a flag expecting > a value has been set. For example, -XX:MaxMetaspaceSize=100m can be > checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ > > Testing: > - JPRT > - hotspot/test/gc (including updated and new tests) > > Thanks, > Erik > From alejandro.murillo at oracle.com Fri Sep 13 04:09:59 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 13 Sep 2013 11:09:59 +0000 Subject: hg: hsx/hsx25/hotspot: 11 new changesets Message-ID: <20130913111044.9EBFB627CD@hg.openjdk.java.net> Changeset: 9cd0183fe325 Author: cl Date: 2013-09-12 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9cd0183fe325 Added tag jdk8-b107 for changeset 5b7f90aab3ad ! .hgtags Changeset: 313b724f8911 Author: amurillo Date: 2013-09-06 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/313b724f8911 8024258: new hotspot build - hs25-b50 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ceda33ff54a3 Author: iignatyev Date: 2013-09-05 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ceda33ff54a3 8012447: Java CTW implementation Reviewed-by: vlivanov, kvn, twisti ! test/gc/TestVerifyDuringStartup.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/ctw/Makefile + test/testlibrary/ctw/README + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java + test/testlibrary/ctw/test/Bar.java + test/testlibrary/ctw/test/ClassesDirTest.java + test/testlibrary/ctw/test/ClassesListTest.java + test/testlibrary/ctw/test/CtwTest.java + test/testlibrary/ctw/test/Foo.java + test/testlibrary/ctw/test/JarDirTest.java + test/testlibrary/ctw/test/JarsTest.java + test/testlibrary/ctw/test/classes.lst + test/testlibrary/whitebox/Makefile Changeset: cd16d587b0fa Author: adlertz Date: 2013-09-09 19:53 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd16d587b0fa Merge Changeset: 72a567cce06f Author: anoll Date: 2013-09-10 07:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/72a567cce06f 8024473: Remove unused macro: IRT_ENTRY_FOR_NMETHOD Summary: Removed unused macro Reviewed-by: kvn, adlertz ! src/share/vm/runtime/interfaceSupport.hpp Changeset: edb5ab0f3fe5 Author: vlivanov Date: 2013-09-10 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/edb5ab0f3fe5 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: rbackman, twisti, kvn Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/accessFlags.hpp Changeset: e0d33d2ce5aa Author: vlivanov Date: 2013-09-10 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0d33d2ce5aa Merge Changeset: 34bd5e86aadb Author: adlertz Date: 2013-09-11 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/34bd5e86aadb 8010941: MinJumpTableSize is set to 18, investigate if that's still optimal Summary: Lowered the MinJumpTableSize for each platform Reviewed-by: kvn ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/share/vm/opto/c2_globals.hpp Changeset: 0821b5d72ca8 Author: adlertz Date: 2013-09-12 09:10 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0821b5d72ca8 Merge Changeset: a09fe9d1e016 Author: amurillo Date: 2013-09-13 00:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a09fe9d1e016 Merge Changeset: 85072013aad4 Author: amurillo Date: 2013-09-13 00:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85072013aad4 Added tag hs25-b50 for changeset a09fe9d1e016 ! .hgtags From david.holmes at oracle.com Fri Sep 13 04:21:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 21:21:07 +1000 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <52321447.4000405@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> Message-ID: <5232F523.3090701@oracle.com> On 13/09/2013 5:21 AM, serguei.spitsyn at oracle.com wrote: > On 9/11/13 8:54 PM, David Holmes wrote: >> Hi Dmitry, >> >> It seems odd that you install the new_method even if there was an >> exception. What if the new_method is not valid because of the exception ? > > Coleen suggested this fragment. > New methods will be deallocated with the scratch class in a case of > exception. > It is handled in the doit_prologue where the scratch classes are added > to the CL deallocation list. Ok - I'll take Coleen's word on that ;-) >> >> Also once you've cleared the exception and returned false, the user >> has no information as to why this failed. I understand we don't want >> to hit the guarantee here, but it seems there is a hole in the error >> flow. > > This issue is fixed in a separate bug fix for 8024346 (see another > review request). > Sorry for the confusion here. Okay. Thanks, David > The whole error flow is not perfect but I'm not targetting to make it > perfect now. > Multiple bugs on the limited Metaspace topic were filed by Stefan: > 8017230, 8024345, 8024346. > My role is to apply/test fixes suggested by Stefan and Coleen in the > order the issues were discovered. > > > Thanks, > Serguei > >> >> David >> >> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>> >>> >>> Summary: >>> Handle pending exceptions instead of firing a guarantee() in the >>> JVMTI rewrite_cp_refs_in_method(). >>> >>> >>> Testing: >>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>> Metaspace memory, >>> nsk.jvmti.testlist, >>> nsk.jdi.testlist, >>> Jtreg java/lang/instrument >>> >>> Thanks, >>> Serguei > From david.holmes at oracle.com Fri Sep 13 04:28:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 21:28:55 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5232851B.3000103@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> <5232851B.3000103@oracle.com> Message-ID: <5232F6F7.1010200@oracle.com> Testing ok - v4 should be good to go. Thanks, David On 13/09/2013 1:23 PM, David Holmes wrote: > Still not right. I confused the PlatformEvent logic with the > Parker logic and thought that the check "s < 1" indicated a thread was > definitely blocked; but it doesn't it only means that a thread may be > blocked. Hence if the thread is not blocked _cur_index == -1 and the > assert trips. So remove the assert and add a check for _cur_index != -1, > as that means a thread is definitely blocked. > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ > > but testing still TBD so hold off on further reviews. > > The logic is messy now with yet-another mutex-unlock having to be added, > but I wanted to minimize the potential change - let me know if you think > it worthwhile refactoring. > > Thanks, > David > > On 13/09/2013 10:59 AM, David Holmes wrote: >> On 13/09/2013 9:30 AM, Daniel D. Daugherty wrote: >>> On 9/12/13 3:47 PM, David Holmes wrote: >>>> >>>> I found a bug in the assertion related logic - new webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ >>>> >>>> For the untimed case in park I wasn't setting the _cur_index value (I >>>> was implicitly using zero) and so the assertion it wasn't -1 was >>>> failing in unpark. >>> >>> So is the usage model for timed park() such that no other thread >>> is calling unpark() on the thread that called timed park()? >>> >>> If another thread can call unpark() on a thread calling timed park(), >>> then I think you may have a race in: >>> >>> 5917 assert(_cur_index != -1, "invariant"); >>> >>> The thread calling unpark() might reach the assertion after the >>> thread that made the timed call to park() set: >>> >>> 5888 _cur_index = -1; >>> >>> Don't know if it's really possible, but... >> >> The code you refer to is all inside a critical region locked with the >> mutex. No races possible. >> >> >>>> With regard to assert versus assert_status - yes this would work: >>>> >>>> assert_status(status == 0, errno, "gettimeofday"); >>>> >>>> I had never considered that. :) When I added assert_status to diagnoze >>>> a particular issue I never attempted to change all the existing >>>> asserts on the library calls. So we have a lot of simple >>>> "assert(status==0,"invariant") where assert_status could have been >>>> used, as well as the old gettimeofday style calls. Do you want me to >>>> change them all in os_linux.cpp? >>> >>> I guess that depends on whether we think this fix will need to be >>> backported to HSX-24 or earlier... Less changes, the better, if a >>> backport is in the future... >> >> Yes backports to 7 and 6 are definitely on the cards. The >> assert/assert_status can be cleaned up as part of the big cleanup for 9 >> (where a lot of the calls will disappear anyway as we get rid of all the >> ancient workarounds). So I will leave this aspect as is. >> >> Thanks, >> David >> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: >>>>> On 9/11/13 5:14 PM, David Holmes wrote: >>>>>> updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ >>>>> >>>>> Looks good. Possibly modulo one comment below... >>>>> >>>>> >>>>>> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >>>>>> >>>>>>> line 5541: assert_status(status == 0, status, "clock_gettime"); >>>>>>> line 5553: assert(status == 0, "gettimeofday"); >>>>>>> So why is one an assert_status() call and the other is a >>>>>>> plain old assert() call? >>>>>> >>>>>> Different API's. The old unix API's, like gettimeofday return -1 on >>>>>> error and set errno. The "modern" posix APIs, eg pthread APIs and >>>>>> clock_gettime etc, return the actual error code on error - hence >>>>>> assert_status can be used to show the actual error in that case. >>>>> >>>>> I don't quite get what you're trying to say here. >>>>> It seems that both calls are trying to verify >>>>> that "status == 0". Or are you saying that: >>>>> >>>>> assert_status(status == 0, status, "gettimeofday"); >>>>> >>>>> is kind of a waste because "status" always be either "0" or "-1". >>>>> So how about this: >>>>> >>>>> assert_status(status == 0, errno, "gettimeofday"); >>>>> >>>>> instead? That pattern should work to get more info. >>>>> >>>>> Dan >>>>> >>> From david.holmes at oracle.com Fri Sep 13 04:40:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 21:40:13 +1000 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <52325A6C.7050007@oracle.com> References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com> <52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com> Message-ID: <5232F99D.90101@oracle.com> Thanks - no further comments. David On 13/09/2013 10:21 AM, serguei.spitsyn at oracle.com wrote: > The updated open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/ > > > Thanks, > Serguei > > On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote: >> On 9/11/13 9:09 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> This is more consistent with the surrounding code, but: >>> >>> 1. Why no RC_TRACE_WITH_THREAD for this case? >> >> Ok, I'll add tracing code. >> >>> >>> 2. If an exception is pending, that isn't OOME, shouldn't "res" >>> already not be JVMTI_ERROR_NONE and so res should be returned in the >>> non-OOME case? >> >> Initially it was my concern as well. >> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL >> are expected from the merge_cp_and_rewrite(). >> So, it is better to keep it simple as in the webrev. >> >> >> Thanks, >> Serguei >> >>> >>> David >>> >>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 >>>> >>>> >>>> >>>> Summary: >>>> Pending exceptions must be handled properly after a call to the >>>> JVMTI >>>> merge_cp_and_rewrite. >>>> >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>> Metaspace memory, >>>> nsk.jvmti.testlist, >>>> nsk.jdi.testlist, >>>> Jtreg java/lang/instrument >>>> >>>> Thanks, >>>> Serguei >>>> >> > From david.holmes at oracle.com Fri Sep 13 04:41:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2013 21:41:59 +1000 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <52325A01.9090405@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> <52323391.3050108@oracle.com> <523258B7.4000409@oracle.com> <52325A01.9090405@oracle.com> Message-ID: <5232FA07.2060504@oracle.com> Looks good to me. Thanks, David On 13/09/2013 10:19 AM, serguei.spitsyn at oracle.com wrote: > The update open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ > > > Thanks, > Serguei > > > On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ >> >> >> Thanks, >> Serguei >> >> >> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote: >>> On 9/11/13 9:04 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Typo: >>>> >>>> 2489 // scratch_cp is a merged constant po/ ol >>> >>> Fixed, thanks! >>> >>>> >>>> >>>> In VM_RedefineClasses::set_new_constant_pool do you not need to >>>> de-allocate smaller_cp if you return due to an exception here: >>>> >>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, >>>> 1, CHECK); >>> >>> Good catch. >>> It is better to deallocate it even if it is not very useful. >>> The only exception possible here is an OOME (Metadata shortage). >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ----- >>>> >>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >>>>> >>>>> >>>>> >>>>> Summary: >>>>> The OOME's in the JVMTI merge_cp_and_rewrite and >>>>> set_new_constant_pool must be handled correctly. >>>>> >>>>> >>>>> Testing: >>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>> Metaspace memory, >>>>> nsk.jvmti.testlist, >>>>> nsk.jdi.testlist, >>>>> Jtreg java/lang/instrument >>>>> >>>>> Thanks, >>>>> Serguei >>> >> > From stefan.karlsson at oracle.com Fri Sep 13 04:55:49 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 Sep 2013 13:55:49 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5231DB36.6080101@oracle.com> References: <5231DB36.6080101@oracle.com> Message-ID: <5232FD45.1030208@oracle.com> http://cr.openjdk.java.net/~stefank/8024650/webrev.01/ Changed in this revision: - Removed incorrect FLAG_IS_DEFAULT check - Added MetaspaceSize <= MaxMetaspaceSize assert - Added boundary test cases where MetaspaceSize and MaxMetaspaceSize is set to 0. - Added rudimentary tests for the new firstMatch function. Rejected proposals: - Use MXBeans to get flag values. - Use WBApi to get conservative max heap alignment. thanks, StefanK On 09/12/2013 05:18 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ > > - Limit MetaspaceSize to MaxMetaspaceSize > - Make sure we don't align down to 0. > - jtreg test > > Note that this patch also adds/changes some functionality in the > OutputAnalyzer in test/testlibrary. > > thanks, > StefanK From coleen.phillimore at oracle.com Fri Sep 13 05:42:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 13 Sep 2013 08:42:13 -0400 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <5232CD0E.4070202@oracle.com> References: <523221AB.6040103@oracle.com> <52322284.4000601@oracle.com> <5232CC12.9050103@oracle.com> <5232CD0E.4070202@oracle.com> Message-ID: <52330825.8020702@oracle.com> Stefan, This looks good. Coleen On 9/13/2013 4:30 AM, Stefan Karlsson wrote: > On 09/13/2013 10:25 AM, Mikael Gerdin wrote: >> Stefan, >> >> On 2013-09-12 22:22, Stefan Karlsson wrote: >>> Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this change >>> code that are shared between different HotSpot sub-components. >>> >>> StefanK >>> >>> -------- Original Message -------- >>> Subject: Review request: 8024752: Log TraceMetadata* output to >>> gclog_or_tty instead of tty >>> Date: Thu, 12 Sep 2013 22:18:51 +0200 >>> From: Stefan Karlsson >>> To: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> >>> http://cr.openjdk.java.net/~stefank/8024752/webrev.00 >> >> The change looks good. > > Thanks, Mikael. > > StefanK > >> >> /Mikael >> >>> >>> The output you get when turning on the TraceMetadata* flags end up in >>> different files. This makes these flags hard to use. >>> >>> The patch directs the output to the gclog_or_tty output stream. >>> >>> thanks, >>> StefanK >>> >>> > From bengt.rutisson at oracle.com Fri Sep 13 05:47:13 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 13 Sep 2013 14:47:13 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5232FD45.1030208@oracle.com> References: <5231DB36.6080101@oracle.com> <5232FD45.1030208@oracle.com> Message-ID: <52330951.3050708@oracle.com> Looks good. Bengt On 9/13/13 1:55 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024650/webrev.01/ > > Changed in this revision: > - Removed incorrect FLAG_IS_DEFAULT check > - Added MetaspaceSize <= MaxMetaspaceSize assert > - Added boundary test cases where MetaspaceSize and MaxMetaspaceSize > is set to 0. > - Added rudimentary tests for the new firstMatch function. > > Rejected proposals: > - Use MXBeans to get flag values. > - Use WBApi to get conservative max heap alignment. > > thanks, > StefanK > > > On 09/12/2013 05:18 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ >> >> - Limit MetaspaceSize to MaxMetaspaceSize >> - Make sure we don't align down to 0. >> - jtreg test >> >> Note that this patch also adds/changes some functionality in the >> OutputAnalyzer in test/testlibrary. >> >> thanks, >> StefanK > From thomas.schatzl at oracle.com Fri Sep 13 05:54:11 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 Sep 2013 14:54:11 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5232FD45.1030208@oracle.com> References: <5231DB36.6080101@oracle.com> <5232FD45.1030208@oracle.com> Message-ID: <1379076851.2466.6.camel@cirrus> Hi, On Fri, 2013-09-13 at 13:55 +0200, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024650/webrev.01/ > > Changed in this revision: > - Removed incorrect FLAG_IS_DEFAULT check > - Added MetaspaceSize <= MaxMetaspaceSize assert > - Added boundary test cases where MetaspaceSize and MaxMetaspaceSize is > set to 0. > - Added rudimentary tests for the new firstMatch function. > > Rejected proposals: > - Use MXBeans to get flag values. > - Use WBApi to get conservative max heap alignment. :) Looks good. Thomas From alejandro.murillo at oracle.com Fri Sep 13 07:19:02 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 13 Sep 2013 14:19:02 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130913141922.5A082627ED@hg.openjdk.java.net> Changeset: 9cd0183fe325 Author: cl Date: 2013-09-12 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9cd0183fe325 Added tag jdk8-b107 for changeset 5b7f90aab3ad ! .hgtags Changeset: a09fe9d1e016 Author: amurillo Date: 2013-09-13 00:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a09fe9d1e016 Merge Changeset: 85072013aad4 Author: amurillo Date: 2013-09-13 00:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85072013aad4 Added tag hs25-b50 for changeset a09fe9d1e016 ! .hgtags Changeset: e42e456fbe6e Author: amurillo Date: 2013-09-13 00:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e42e456fbe6e 8024764: new hotspot build - hs25-b51 Reviewed-by: jcoomes ! make/hotspot_version From karen.kinnear at oracle.com Fri Sep 13 07:38:25 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 13 Sep 2013 10:38:25 -0400 Subject: Result: New hsx Comitter: Calvin Cheung Message-ID: <531A57E1-255D-4A91-8674-CDEA9A7C2662@oracle.com> Voting for Calvin Cheung [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Karen Kinnear [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-August/010674.html From daniel.daugherty at oracle.com Fri Sep 13 10:03:55 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 13 Sep 2013 11:03:55 -0600 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5232851B.3000103@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> <5232851B.3000103@oracle.com> Message-ID: <5233457B.4030307@oracle.com> > http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ I think you want to get some other eyes on this change. This is my fourth review and I'm not catching everything. Or I'm catching something, but not for exactly the right reasons. src/os/linux/vm/os_linux.hpp No comments. src/os/linux/vm/os_linux.cpp No comments. On 9/12/13 9:23 PM, David Holmes wrote: > Still not right. I confused the PlatformEvent logic with the > Parker logic and thought that the check "s < 1" indicated a thread was > definitely blocked; but it doesn't it only means that a thread may be > blocked. Hence if the thread is not blocked _cur_index == -1 and the > assert trips. So remove the assert and add a check for _cur_index != > -1, as that means a thread is definitely blocked. Yup. So it was possible for the assert() in unpark() to race with the value of _cur_index. Not for the reason I thought so not my catch here. > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ > > but testing still TBD so hold off on further reviews. > > The logic is messy now with yet-another mutex-unlock having to be > added, but I wanted to minimize the potential change - let me know if > you think it worthwhile refactoring. Strangely enough, the new version seems more clear to me. Please don't refactor; that can wait for JDK9. Dan > > Thanks, > David > > On 13/09/2013 10:59 AM, David Holmes wrote: >> On 13/09/2013 9:30 AM, Daniel D. Daugherty wrote: >>> On 9/12/13 3:47 PM, David Holmes wrote: >>>> >>>> I found a bug in the assertion related logic - new webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ >>>> >>>> For the untimed case in park I wasn't setting the _cur_index value (I >>>> was implicitly using zero) and so the assertion it wasn't -1 was >>>> failing in unpark. >>> >>> So is the usage model for timed park() such that no other thread >>> is calling unpark() on the thread that called timed park()? >>> >>> If another thread can call unpark() on a thread calling timed park(), >>> then I think you may have a race in: >>> >>> 5917 assert(_cur_index != -1, "invariant"); >>> >>> The thread calling unpark() might reach the assertion after the >>> thread that made the timed call to park() set: >>> >>> 5888 _cur_index = -1; >>> >>> Don't know if it's really possible, but... >> >> The code you refer to is all inside a critical region locked with the >> mutex. No races possible. >> >> >>>> With regard to assert versus assert_status - yes this would work: >>>> >>>> assert_status(status == 0, errno, "gettimeofday"); >>>> >>>> I had never considered that. :) When I added assert_status to diagnoze >>>> a particular issue I never attempted to change all the existing >>>> asserts on the library calls. So we have a lot of simple >>>> "assert(status==0,"invariant") where assert_status could have been >>>> used, as well as the old gettimeofday style calls. Do you want me to >>>> change them all in os_linux.cpp? >>> >>> I guess that depends on whether we think this fix will need to be >>> backported to HSX-24 or earlier... Less changes, the better, if a >>> backport is in the future... >> >> Yes backports to 7 and 6 are definitely on the cards. The >> assert/assert_status can be cleaned up as part of the big cleanup for 9 >> (where a lot of the calls will disappear anyway as we get rid of all the >> ancient workarounds). So I will leave this aspect as is. >> >> Thanks, >> David >> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: >>>>> On 9/11/13 5:14 PM, David Holmes wrote: >>>>>> updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ >>>>> >>>>> Looks good. Possibly modulo one comment below... >>>>> >>>>> >>>>>> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >>>>>> >>>>>>> line 5541: assert_status(status == 0, status, >>>>>>> "clock_gettime"); >>>>>>> line 5553: assert(status == 0, "gettimeofday"); >>>>>>> So why is one an assert_status() call and the other is a >>>>>>> plain old assert() call? >>>>>> >>>>>> Different API's. The old unix API's, like gettimeofday return -1 on >>>>>> error and set errno. The "modern" posix APIs, eg pthread APIs and >>>>>> clock_gettime etc, return the actual error code on error - hence >>>>>> assert_status can be used to show the actual error in that case. >>>>> >>>>> I don't quite get what you're trying to say here. >>>>> It seems that both calls are trying to verify >>>>> that "status == 0". Or are you saying that: >>>>> >>>>> assert_status(status == 0, status, "gettimeofday"); >>>>> >>>>> is kind of a waste because "status" always be either "0" or "-1". >>>>> So how about this: >>>>> >>>>> assert_status(status == 0, errno, "gettimeofday"); >>>>> >>>>> instead? That pattern should work to get more info. >>>>> >>>>> Dan >>>>> >>> > > From christian.thalinger at oracle.com Fri Sep 13 10:21:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 13 Sep 2013 10:21:16 -0700 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs In-Reply-To: <4D241E5E-B526-4BAB-9E3A-A770C91C20A1@oracle.com> References: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> <52326828.7030609@oracle.com> <4D241E5E-B526-4BAB-9E3A-A770C91C20A1@oracle.com> Message-ID: I'm going to add one more constant and then push it: + declare_preprocessor_constant("ASSERT", DEBUG_ONLY(1) NOT_DEBUG(0)) \ -- Chris On Sep 12, 2013, at 7:29 PM, Christian Thalinger wrote: > Thank you, Vladimir. -- Chris > > On Sep 12, 2013, at 6:19 PM, Vladimir Kozlov wrote: > >> Good. >> >> Vladimir >> >> On 9/12/13 6:06 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/8024760/webrev/ >>> >>> 8024760: add more types, fields and constants to VMStructs >>> Reviewed-by: >>> >>> Some types, fields and constants we need to investigate bugs. >>> >>> There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. >>> >>> agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >>> src/share/vm/gc_implementation/g1/ptrQueue.hpp >>> src/share/vm/memory/universe.cpp >>> src/share/vm/memory/universe.hpp >>> src/share/vm/oops/klassVtable.hpp >>> src/share/vm/oops/methodData.hpp >>> src/share/vm/runtime/os.hpp >>> src/share/vm/runtime/vmStructs.cpp >>> > From christian.thalinger at oracle.com Fri Sep 13 10:25:01 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 13 Sep 2013 10:25:01 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> Message-ID: <11D02AE2-7CD7-4CB6-81CA-F16421301DB0@oracle.com> On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: > > On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: > >> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>> >>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>> >>>> Christian, >>>> >>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>> >>> Yes, good point. >>> >>>> >>>> It would be nice enumerate flag's type and use int instead of strings: >>>> >>>> enum { >>>> bool_flag = 1, >>>> intx_flag = 2, >>>> >>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>> >>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >> >> Do it in separate changes after you push this. FTR: 8024803: move Flag::_type to Flag::_flags -- Chris >> And if you remove _type field later you don't need to move _flags now. >> So you can push your current changes as it is. They are good. > > Thank you, Vladimir. -- Chris > >> >> Thanks, >> Vladimir >> >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>> >>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>> >>>>>> Hi Chris, >>>>>> >>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>> >>>>>> + if (is_constant_in_binary()) { >>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>> >>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>> >>>>> Good point. I made that change: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>> >>>>>> >>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>> >>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>> >>>>>> >>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>> >>>>> The 32-bit product build also contains the server compiler. >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>> >>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>> >>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>> >>>>>>> Before: >>>>>>> >>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>> Attaching to process 9399, please wait... >>>>>>> hsdb> flags -nd >>>>>>> InitialHeapSize = 495006528 5 >>>>>>> MaxHeapSize = 7920943104 5 >>>>>>> UseCompressedKlassPointers = true 5 >>>>>>> UseCompressedOops = true 5 >>>>>>> UseParallelGC = true 5 >>>>>>> hsdb> flags InlineMathNatives >>>>>>> Couldn't find flag: InlineMathNatives >>>>>>> >>>>>>> After: >>>>>>> >>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>> Attaching to process 3726, please wait... >>>>>>> hsdb> flags -nd >>>>>>> InitialHeapSize = 495006528 5 >>>>>>> MaxHeapSize = 7920943104 5 >>>>>>> UseCompressedKlassPointers = true 5 >>>>>>> UseCompressedOops = true 5 >>>>>>> UseParallelGC = true 5 >>>>>>> hsdb> flags InlineMathNatives >>>>>>> InlineMathNatives = true 0 >>>>>>> >>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>> >>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>> >>>>>>> The output for product builds is unchanged. >>>>>>> >>>>> >>> > From serguei.spitsyn at oracle.com Fri Sep 13 10:36:47 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Sep 2013 10:36:47 -0700 Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool In-Reply-To: <5232FA07.2060504@oracle.com> References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com> <52323391.3050108@oracle.com> <523258B7.4000409@oracle.com> <52325A01.9090405@oracle.com> <5232FA07.2060504@oracle.com> Message-ID: <52334D2F.5080403@oracle.com> Thank you, David! Serguei On 9/13/13 4:41 AM, David Holmes wrote: > Looks good to me. > > Thanks, > David > > On 13/09/2013 10:19 AM, serguei.spitsyn at oracle.com wrote: >> The update open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ >> >> >> >> Thanks, >> Serguei >> >> >> On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote: >>>> On 9/11/13 9:04 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Typo: >>>>> >>>>> 2489 // scratch_cp is a merged constant po/ ol >>>> >>>> Fixed, thanks! >>>> >>>>> >>>>> >>>>> In VM_RedefineClasses::set_new_constant_pool do you not need to >>>>> de-allocate smaller_cp if you return due to an exception here: >>>>> >>>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, >>>>> 1, CHECK); >>>> >>>> Good catch. >>>> It is better to deallocate it even if it is not very useful. >>>> The only exception possible here is an OOME (Metadata shortage). >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345 >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The OOME's in the JVMTI merge_cp_and_rewrite and >>>>>> set_new_constant_pool must be handled correctly. >>>>>> >>>>>> >>>>>> Testing: >>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>>> Metaspace memory, >>>>>> nsk.jvmti.testlist, >>>>>> nsk.jdi.testlist, >>>>>> Jtreg java/lang/instrument >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> >> From serguei.spitsyn at oracle.com Fri Sep 13 10:37:25 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Sep 2013 10:37:25 -0700 Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated In-Reply-To: <5232F99D.90101@oracle.com> References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com> <52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com> <5232F99D.90101@oracle.com> Message-ID: <52334D55.8080004@oracle.com> Thanks! Serguei On 9/13/13 4:40 AM, David Holmes wrote: > Thanks - no further comments. > > David > > On 13/09/2013 10:21 AM, serguei.spitsyn at oracle.com wrote: >> The updated open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/ >> >> >> >> Thanks, >> Serguei >> >> On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote: >>> On 9/11/13 9:09 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> This is more consistent with the surrounding code, but: >>>> >>>> 1. Why no RC_TRACE_WITH_THREAD for this case? >>> >>> Ok, I'll add tracing code. >>> >>>> >>>> 2. If an exception is pending, that isn't OOME, shouldn't "res" >>>> already not be JVMTI_ERROR_NONE and so res should be returned in the >>>> non-OOME case? >>> >>> Initially it was my concern as well. >>> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL >>> are expected from the merge_cp_and_rewrite(). >>> So, it is better to keep it simple as in the webrev. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> >>>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the fix for: >>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1 >>>>> >>>>> >>>>> >>>>> >>>>> Summary: >>>>> Pending exceptions must be handled properly after a call to the >>>>> JVMTI >>>>> merge_cp_and_rewrite. >>>>> >>>>> >>>>> >>>>> Testing: >>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>>> Metaspace memory, >>>>> nsk.jvmti.testlist, >>>>> nsk.jdi.testlist, >>>>> Jtreg java/lang/instrument >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>> >> From serguei.spitsyn at oracle.com Fri Sep 13 10:41:23 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Sep 2013 10:41:23 -0700 Subject: Review Request (S) 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed In-Reply-To: <5232F523.3090701@oracle.com> References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com> <52321447.4000405@oracle.com> <5232F523.3090701@oracle.com> Message-ID: <52334E43.4050902@oracle.com> Thank you for the review! Serguei On 9/13/13 4:21 AM, David Holmes wrote: > On 13/09/2013 5:21 AM, serguei.spitsyn at oracle.com wrote: >> On 9/11/13 8:54 PM, David Holmes wrote: >>> Hi Dmitry, >>> >>> It seems odd that you install the new_method even if there was an >>> exception. What if the new_method is not valid because of the >>> exception ? >> >> Coleen suggested this fragment. >> New methods will be deallocated with the scratch class in a case of >> exception. >> It is handled in the doit_prologue where the scratch classes are added >> to the CL deallocation list. > > Ok - I'll take Coleen's word on that ;-) > >>> >>> Also once you've cleared the exception and returned false, the user >>> has no information as to why this failed. I understand we don't want >>> to hit the guarantee here, but it seems there is a hole in the error >>> flow. >> >> This issue is fixed in a separate bug fix for 8024346 (see another >> review request). >> Sorry for the confusion here. > > Okay. > > Thanks, > David > >> The whole error flow is not perfect but I'm not targetting to make it >> perfect now. >> Multiple bugs on the limited Metaspace topic were filed by Stefan: >> 8017230, 8024345, 8024346. >> My role is to apply/test fixes suggested by Stefan and Coleen in the >> order the issues were discovered. >> >> >> Thanks, >> Serguei >> >>> >>> David >>> >>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1 >>>> >>>> >>>> >>>> Summary: >>>> Handle pending exceptions instead of firing a guarantee() in the >>>> JVMTI rewrite_cp_refs_in_method(). >>>> >>>> >>>> Testing: >>>> UTE tests - in progress: vm.quick-pcl.testlist with limited >>>> Metaspace memory, >>>> nsk.jvmti.testlist, >>>> nsk.jdi.testlist, >>>> Jtreg java/lang/instrument >>>> >>>> Thanks, >>>> Serguei >> From aleksey.shipilev at oracle.com Fri Sep 13 10:49:46 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 13 Sep 2013 21:49:46 +0400 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5233457B.4030307@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> <5232851B.3000103@oracle.com> <5233457B.4030307@oracle.com> Message-ID: <5233503A.8030607@oracle.com> On 09/13/2013 09:03 PM, Daniel D. Daugherty wrote: >> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ > > I think you want to get some other eyes on this change. This is > my fourth review and I'm not catching everything. Or I'm catching > something, but not for exactly the right reasons. (Granted, I have mediocre experience with Linux APIs). Nothing pops out for me. Thumbs up. Stylistic: "++absTime->tv_sec;" bothers me. There seems to be no reason to not to use post-increment rather than let the readers infer what is being incremented, and if the precedence rules play dirty here. -Aleksey. From christian.tornqvist at oracle.com Fri Sep 13 11:52:07 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 13 Sep 2013 14:52:07 -0400 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <5232F2CB.8050902@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> Message-ID: <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> I've added getCompileJDKTool() and getTestJDKTool(), the common function getJDKTool() will still look in test.jdk first and compile.jdk as a fallback. Changed the TestVerifyDuringStartup.java that Igor changed as part of his change to use getJDKTool() since this is what ProcessTools.createJavaProcessBuilder() does. Verified my change locally by running test/runtime and test/gc jtreg tests to verify that they work correctly when test.jdk is set to a JRE. New webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ Thanks, Christian -----Original Message----- From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Friday, September 13, 2013 7:11 AM To: Erik Helin Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk Just to cc the list what I said in other email ... I think this is a good compromise. Having an API that allows the test to select which JDK to use is important; but maintaining compatability with existing test behaviour is also important. Thanks, David On 12/09/2013 11:22 PM, Erik Helin wrote: > On 2013-09-12, David Holmes wrote: >> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>> Christian, >>>>>>> >>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>> JDK-8012447[*]: >>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>> >>>>>>> So, I'm not sure that your change is necessary. >>>>>> >>>>>> I prefer Christian's approach as it is behaviour preserving. With >>>>>> your change any test that actually wants/needs to use the test >>>>>> JDK will have to be modified. >>>>> I agree, but w/ Christian's approach we could get situation that >>>>> we test binary from another JDK, e.g. >>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>> >>>> I don't see how as the test JDK is checked first. The gap in >>>> Christian's approach is the more rare case of where the test JDKs >>>> tool must not be used for that part of the test. >>> Oh sorry, I misread the code. Anyway, I don't think that this code >>> is good, because if I want to get one of jdk tool, I expect that I >>> will get it from '-compilejdk' if this option's specified, and from >>> '-jdk', otherwise. But w/ Christian's patch I will get tool from >>> '-jdk' if tool exists there, that may confuse. >> >> Anyone using this function has to know what it returns regardless of >> whether that is from compile-jdk or test-jdk. With your change a >> bunch of tests that were using the test-jdk tools will now be using >> the compile-jdk tools, and while that might not cause a test failure >> it might negate the purpose of the test. So unless you've examined >> all the tests that use this API I can't agree that your change was >> appropriate. > > I, Igor and Christian discussed this on IM and the solution that we > came up with was that JDKToolFinder should have three methods: > getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool should, > as in Christian's change, first try to make use of getTestJDKTool and > then, if that fails, use getCompilerJDKTool. > > getCompilerJDKTool and getTestJDKTool should be like the ones Igor has > written, but the should use make use of a private function to avoid > code duplication. > > This way, writing an simple test will still be easy, using getJDKTool > should in most cases be what you want. However, if you are writing a > more tricky test, getTestJDKTool and getCompilerJDKTool are still > there for those cases. > > David, what do think about this suggestion? > >>>> So I think >>>>> that any test that actually wants/needs to use the test JDK must >>>>> do it explicitly. >>>>>> >>>>>>> [*] >>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33ff >>>>>>> 54a3 >>>>>> >>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>> hotspot-compiler-dev? >>>>> >>>>> It was reviewed only on hotspot-compiler-dev. >>>> >>>> These kinds of changes really have to be reviewed more broadly as >>>> they affect everyone. We wouldn't even have known about your change >>>> if Christian hadn't done this one. Plus the testlibrary really >>>> should have a nominal owner to coordinate things - and we need to >>>> make sure the hotspot and JDK versions are kept in sync. > > I guess that I and Christian usually try to monitor the changes to the > hotspot testlibrary, and I think Igor will start do it as well :) This > way, we at least have one from runtime, one from compiler and one from > gc. > > As for keeping the JDK and HotSpot versions in sync, well that is a > problem. One of the issues is that just because we in the hotspot team > reviewed and approved changes to HotSpot's testlibrary does not > automatically mean that the JDK team wants these patches. Therefore, > keeping the JDK and the HotSpot test libraries in sync will require > more work than just "moving patches". > > Unfortunately, I do not have any good solution for this at the moment > :( > >>> I fully agree w/ you and I'm really sorry about the situation. >>> But I don't see big difference between 'hotspot-runtime-dev' and >>> 'hotspot-compiler-dev', so *this* change "really have to be reviewed >>> more broadly as they affect everyone". >> >> I meant reviewing on hotspot-runtime-dev as well as >> hotspot-compiler-dev, not in place of. hotspot-dev could have been in >> place. > > I think hotspot-dev is better for changes to the hotspot testlibrary > since the changes affect all the hotspot devevelopers. > > Thanks, > Erik > >> Cheers, >> David >> >>>> Thanks, >>>> David >>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Igor Ignatyev >>>>>>> >>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02/ >>>>>>>> >>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Christian >>>>>>>> From harold.seigel at oracle.com Fri Sep 13 12:47:06 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 13 Sep 2013 15:47:06 -0400 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> Message-ID: <52336BBA.9030409@oracle.com> Hi Christian, The changes look good. Harold On 9/13/2013 2:52 PM, Christian Tornqvist wrote: > I've added getCompileJDKTool() and getTestJDKTool(), the common function getJDKTool() will still look in test.jdk first and compile.jdk as a fallback. > > Changed the TestVerifyDuringStartup.java that Igor changed as part of his change to use getJDKTool() since this is what ProcessTools.createJavaProcessBuilder() does. > > Verified my change locally by running test/runtime and test/gc jtreg tests to verify that they work correctly when test.jdk is set to a JRE. > > New webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev-bounces at openjdk.java.net > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David > Holmes > Sent: Friday, September 13, 2013 7:11 AM > To: Erik Helin > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be > updated to divide test jdk and compile jdk > > Just to cc the list what I said in other email ... > > I think this is a good compromise. Having an API that allows the test to > select which JDK to use is important; but maintaining compatability with > existing test behaviour is also important. > > Thanks, > David > > On 12/09/2013 11:22 PM, Erik Helin wrote: >> On 2013-09-12, David Holmes wrote: >>> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>>> Christian, >>>>>>>> >>>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>>> JDK-8012447[*]: >>>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>>> >>>>>>>> So, I'm not sure that your change is necessary. >>>>>>> I prefer Christian's approach as it is behaviour preserving. With >>>>>>> your change any test that actually wants/needs to use the test >>>>>>> JDK will have to be modified. >>>>>> I agree, but w/ Christian's approach we could get situation that >>>>>> we test binary from another JDK, e.g. >>>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>>> I don't see how as the test JDK is checked first. The gap in >>>>> Christian's approach is the more rare case of where the test JDKs >>>>> tool must not be used for that part of the test. >>>> Oh sorry, I misread the code. Anyway, I don't think that this code >>>> is good, because if I want to get one of jdk tool, I expect that I >>>> will get it from '-compilejdk' if this option's specified, and from >>>> '-jdk', otherwise. But w/ Christian's patch I will get tool from >>>> '-jdk' if tool exists there, that may confuse. >>> Anyone using this function has to know what it returns regardless of >>> whether that is from compile-jdk or test-jdk. With your change a >>> bunch of tests that were using the test-jdk tools will now be using >>> the compile-jdk tools, and while that might not cause a test failure >>> it might negate the purpose of the test. So unless you've examined >>> all the tests that use this API I can't agree that your change was >>> appropriate. >> I, Igor and Christian discussed this on IM and the solution that we >> came up with was that JDKToolFinder should have three methods: >> getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool should, >> as in Christian's change, first try to make use of getTestJDKTool and >> then, if that fails, use getCompilerJDKTool. >> >> getCompilerJDKTool and getTestJDKTool should be like the ones Igor has >> written, but the should use make use of a private function to avoid >> code duplication. >> >> This way, writing an simple test will still be easy, using getJDKTool >> should in most cases be what you want. However, if you are writing a >> more tricky test, getTestJDKTool and getCompilerJDKTool are still >> there for those cases. >> >> David, what do think about this suggestion? >> >>>>> So I think >>>>>> that any test that actually wants/needs to use the test JDK must >>>>>> do it explicitly. >>>>>>>> [*] >>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33ff >>>>>>>> 54a3 >>>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>>> hotspot-compiler-dev? >>>>>> It was reviewed only on hotspot-compiler-dev. >>>>> These kinds of changes really have to be reviewed more broadly as >>>>> they affect everyone. We wouldn't even have known about your change >>>>> if Christian hadn't done this one. Plus the testlibrary really >>>>> should have a nominal owner to coordinate things - and we need to >>>>> make sure the hotspot and JDK versions are kept in sync. >> I guess that I and Christian usually try to monitor the changes to the >> hotspot testlibrary, and I think Igor will start do it as well :) This >> way, we at least have one from runtime, one from compiler and one from >> gc. >> >> As for keeping the JDK and HotSpot versions in sync, well that is a >> problem. One of the issues is that just because we in the hotspot team >> reviewed and approved changes to HotSpot's testlibrary does not >> automatically mean that the JDK team wants these patches. Therefore, >> keeping the JDK and the HotSpot test libraries in sync will require >> more work than just "moving patches". >> >> Unfortunately, I do not have any good solution for this at the moment >> :( >> >>>> I fully agree w/ you and I'm really sorry about the situation. >>>> But I don't see big difference between 'hotspot-runtime-dev' and >>>> 'hotspot-compiler-dev', so *this* change "really have to be reviewed >>>> more broadly as they affect everyone". >>> I meant reviewing on hotspot-runtime-dev as well as >>> hotspot-compiler-dev, not in place of. hotspot-dev could have been in >>> place. >> I think hotspot-dev is better for changes to the hotspot testlibrary >> since the changes affect all the hotspot devevelopers. >> >> Thanks, >> Erik >> >>> Cheers, >>> David >>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Best regards, >>>>>>>> Igor Ignatyev >>>>>>>> >>>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02/ >>>>>>>>> >>>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Christian >>>>>>>>> From christian.thalinger at oracle.com Fri Sep 13 12:57:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 13 Sep 2013 12:57:48 -0700 Subject: RFR (M): 8024760: add more types, fields and constants to VMStructs In-Reply-To: References: <2880327A-F01F-4AB5-B0B9-98F55A0173FC@oracle.com> <52326828.7030609@oracle.com> <4D241E5E-B526-4BAB-9E3A-A770C91C20A1@oracle.com> Message-ID: <2A1ADF52-1157-4EC8-B167-F694F9284BA4@oracle.com> After I submitted the integration job I noticed a bug. HeapRegion::LogOfHRGrainBytes is not a constant; it's a static field: + static_field(HeapRegion, LogOfHRGrainBytes, int) \ -- Chris On Sep 13, 2013, at 10:21 AM, Christian Thalinger wrote: > I'm going to add one more constant and then push it: > > + declare_preprocessor_constant("ASSERT", DEBUG_ONLY(1) NOT_DEBUG(0)) \ > > -- Chris > > On Sep 12, 2013, at 7:29 PM, Christian Thalinger wrote: > >> Thank you, Vladimir. -- Chris >> >> On Sep 12, 2013, at 6:19 PM, Vladimir Kozlov wrote: >> >>> Good. >>> >>> Vladimir >>> >>> On 9/12/13 6:06 PM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/8024760/webrev/ >>>> >>>> 8024760: add more types, fields and constants to VMStructs >>>> Reviewed-by: >>>> >>>> Some types, fields and constants we need to investigate bugs. >>>> >>>> There is also a bug fix for intConstant and longConstant. Both commands didn't print the value because the wrong name was passed. >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>> src/share/vm/gc_implementation/g1/ptrQueue.hpp >>>> src/share/vm/memory/universe.cpp >>>> src/share/vm/memory/universe.hpp >>>> src/share/vm/oops/klassVtable.hpp >>>> src/share/vm/oops/methodData.hpp >>>> src/share/vm/runtime/os.hpp >>>> src/share/vm/runtime/vmStructs.cpp >>>> >> > From goetz.lindenmaier at sap.com Fri Sep 13 13:33:55 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Sep 2013 20:33:55 +0000 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <52321DB0.1050103@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> <523110CC.1040307@oracle.com> <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> <52321DB0.1050103@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D02F11E@DEWDFEMB12A.global.corp.sap> Hi, >> Why only intrinsify_fill changed? What about arraycopy and other stubs >> which use int parameter? I figured why we need the adaption of the signature for intrinsify_fill. This stub call is done with a CallLeafNoFPNode, which is child of CallRuntimeNode. Therefore the matcher expects c_calling_conventions. Arraycopy stubs are called with CallStaticJavaNode, thus they are fine. Other stubs just use 64-bit types. Also there is a guarantee() in the ppc c_calling_convention() checking the signature, so that we are sure we did not miss a case. I adapted the type test and moved the functions to the ppc file :( What I don't like is that c_calling_convention_requires_ints_as_longs() can not be inlined by the C Compiler. That's because sharedRuntime has no platform header. Do you have an idea how I could improve this? http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg-2 Also, could I please get a second review? Thanks & best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, September 12, 2013 10:02 PM To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. On 9/12/13 4:42 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp >> to sharedRuntime_ppc.cpp? They are static and not used in any other places. > I really would like to keep this code in the shared file because: > - The code is completely plarform independent. > - The feature needs several shared changes, so I think it's natural to keep all > it's platform independent parts in the shared files. > - Internally, we use it also for zArch, so for us it would reduce code duplication > to have it in the shared file. My concern is about VM size on platforms which do not need this. I wanted to suggest to put it under #ifdef but it will be ugly. > >> Why only intrinsify_fill changed? What about arraycopy and other stubs >> which use int parameter? > Yes, that looks strange. For stub calls that should not be needed, as > we also implement the callee. I'll investigate this in our VM, and try > to remove the change to runtime.cpp and loopTransform.cpp. > I'll come up with a new webrev then. Thanks for pointing me to this! > >> loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also >> you can use (t == T_INT || is_subword_type(t)) check instead for int types. > Above, a MoveF2I is issued, therefore ConvI2L works. Probably conversion > is pointless, but the type is correct then. I missed MoveF2I. Okay then. Thanks, Vladimir > > Thanks for the review and for adapting the closed stuff to 0112. > > Best regards, > Goetz. > > > On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> This is the first of about 10 changes taking us to a rudimentary c2 >> compiler on ppc64. >> >> Some platforms, as ppc and s390x/zArch require that 32-bit ints are >> passed as 64-bit values to C functions. This change adds support to >> adapt the signature and to issue proper casts to c2-compiled stubs. The >> functions are used in generate_native_wrapper(). We also need to adapt >> the signature in PhaseIdealLoop::intrinsify_fill(). >> >> We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with >> >> enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing >> >> platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by >> >> ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp >> >> line 1752 ff. >> >> >> >> http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ >> >> Please review and test this change. >> >> Best regards, >> >> Goetz. >> From goetz.lindenmaier at sap.com Fri Sep 13 14:00:05 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Sep 2013 21:00:05 +0000 Subject: RFR(S): 8024469: PPC64 (part 202): cppInterpreter: support for OSR. Message-ID: <4295855A5C1DE049A61835A1887419CC0D030152@DEWDFEMB12A.global.corp.sap> Hi, to do OSR with the cppInterpreter we need this small fix. http://cr.openjdk.java.net/~goetz/webrevs/8024469-osr The call to osr migration needs proper frame setup. Please review this change. Best regards, Goetz. From vladimir.kozlov at oracle.com Fri Sep 13 15:20:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Sep 2013 15:20:43 -0700 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D02F11E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> <523110CC.1040307@oracle.com> <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> <52321DB0.1050103@oracle.com> <4295855A5C1DE049A61835A1887419CC0D02F11E@DEWDFEMB12A.global.corp.sap> Message-ID: <52338FBB.2070308@oracle.com> On 9/13/13 1:33 PM, Lindenmaier, Goetz wrote: > Hi, > >>> Why only intrinsify_fill changed? What about arraycopy and other stubs >>> which use int parameter? > I figured why we need the adaption of the signature for intrinsify_fill. > This stub call is done with a CallLeafNoFPNode, which is child of > CallRuntimeNode. Therefore the matcher expects c_calling_conventions. > Arraycopy stubs are called with CallStaticJavaNode, thus they are fine. Other stubs > just use 64-bit types. > Also there is a guarantee() in the ppc c_calling_convention() checking > the signature, so that we are sure we did not miss a case. Okay. > > I adapted the type test and moved the functions to the ppc file :( > What I don't like is that c_calling_convention_requires_ints_as_longs() can > not be inlined by the C Compiler. That's because sharedRuntime has > no platform header. Do you have an idea how I could improve this? Yes, if it was inlined we could keep those methods in shared code but their bodies will be guarded by c_calling_convention_requires_ints_as_longs() check and C will optimize them out on platforms we don't need them. May be replace c_calling_convention_requires_ints_as_longs() method with constant in globalDefinitions_.hpp ? Vladimir > http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg-2 > > Also, could I please get a second review? > > Thanks & best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, September 12, 2013 10:02 PM > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. > > > > On 9/12/13 4:42 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp >>> to sharedRuntime_ppc.cpp? They are static and not used in any other places. >> I really would like to keep this code in the shared file because: >> - The code is completely plarform independent. >> - The feature needs several shared changes, so I think it's natural to keep all >> it's platform independent parts in the shared files. >> - Internally, we use it also for zArch, so for us it would reduce code duplication >> to have it in the shared file. > > My concern is about VM size on platforms which do not need this. > I wanted to suggest to put it under #ifdef but it will be ugly. > >> >>> Why only intrinsify_fill changed? What about arraycopy and other stubs >>> which use int parameter? >> Yes, that looks strange. For stub calls that should not be needed, as >> we also implement the callee. I'll investigate this in our VM, and try >> to remove the change to runtime.cpp and loopTransform.cpp. >> I'll come up with a new webrev then. Thanks for pointing me to this! >> >>> loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also >>> you can use (t == T_INT || is_subword_type(t)) check instead for int types. >> Above, a MoveF2I is issued, therefore ConvI2L works. Probably conversion >> is pointless, but the type is correct then. > > I missed MoveF2I. Okay then. > > Thanks, > Vladimir > >> >> Thanks for the review and for adapting the closed stuff to 0112. >> >> Best regards, >> Goetz. >> >> >> On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This is the first of about 10 changes taking us to a rudimentary c2 >>> compiler on ppc64. >>> >>> Some platforms, as ppc and s390x/zArch require that 32-bit ints are >>> passed as 64-bit values to C functions. This change adds support to >>> adapt the signature and to issue proper casts to c2-compiled stubs. The >>> functions are used in generate_native_wrapper(). We also need to adapt >>> the signature in PhaseIdealLoop::intrinsify_fill(). >>> >>> We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with >>> >>> enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing >>> >>> platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by >>> >>> ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp >>> >>> line 1752 ff. >>> >>> >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ >>> >>> Please review and test this change. >>> >>> Best regards, >>> >>> Goetz. >>> From vladimir.kozlov at oracle.com Fri Sep 13 15:22:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Sep 2013 15:22:11 -0700 Subject: RFR(S): 8024469: PPC64 (part 202): cppInterpreter: support for OSR. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D030152@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D030152@DEWDFEMB12A.global.corp.sap> Message-ID: <52339013.2000306@oracle.com> Good. I think you can push it yourself. thanks, Vladimir On 9/13/13 2:00 PM, Lindenmaier, Goetz wrote: > Hi, > > to do OSR with the cppInterpreter we need this small fix. > > http://cr.openjdk.java.net/~goetz/webrevs/8024469-osr > > The call to osr migration needs proper frame setup. > > Please review this change. > > Best regards, > > Goetz. > From david.holmes at oracle.com Fri Sep 13 16:41:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Sep 2013 09:41:13 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5233457B.4030307@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> <5232851B.3000103@oracle.com> <5233457B.4030307@oracle.com> Message-ID: <5233A299.5050807@oracle.com> On 14/09/2013 3:03 AM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ > > I think you want to get some other eyes on this change. This is > my fourth review and I'm not catching everything. Or I'm catching > something, but not for exactly the right reasons. Still need that second reviewer anyway. My fault for not doing full debug testing before asking for review. > src/os/linux/vm/os_linux.hpp > No comments. > > src/os/linux/vm/os_linux.cpp > No comments. > > > On 9/12/13 9:23 PM, David Holmes wrote: >> Still not right. I confused the PlatformEvent logic with the >> Parker logic and thought that the check "s < 1" indicated a thread was >> definitely blocked; but it doesn't it only means that a thread may be >> blocked. Hence if the thread is not blocked _cur_index == -1 and the >> assert trips. So remove the assert and add a check for _cur_index != >> -1, as that means a thread is definitely blocked. > > Yup. So it was possible for the assert() in unpark() to race > with the value of _cur_index. Not for the reason I thought so > not my catch here. Not a race simply a logic error. unpark() is often issued even if the thread is not parked, but the assert assumed a thread had to be parked. > >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ >> >> but testing still TBD so hold off on further reviews. >> >> The logic is messy now with yet-another mutex-unlock having to be >> added, but I wanted to minimize the potential change - let me know if >> you think it worthwhile refactoring. > > Strangely enough, the new version seems more clear to me. > Please don't refactor; that can wait for JDK9. Okay - thanks for re-review. We actually get a performance boost with the new code because now Parker (like PlatformEvent) skips the pthread_cond_signal if no thread is waiting. David > Dan > >> >> Thanks, >> David >> >> On 13/09/2013 10:59 AM, David Holmes wrote: >>> On 13/09/2013 9:30 AM, Daniel D. Daugherty wrote: >>>> On 9/12/13 3:47 PM, David Holmes wrote: >>>>> >>>>> I found a bug in the assertion related logic - new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v3/ >>>>> >>>>> For the untimed case in park I wasn't setting the _cur_index value (I >>>>> was implicitly using zero) and so the assertion it wasn't -1 was >>>>> failing in unpark. >>>> >>>> So is the usage model for timed park() such that no other thread >>>> is calling unpark() on the thread that called timed park()? >>>> >>>> If another thread can call unpark() on a thread calling timed park(), >>>> then I think you may have a race in: >>>> >>>> 5917 assert(_cur_index != -1, "invariant"); >>>> >>>> The thread calling unpark() might reach the assertion after the >>>> thread that made the timed call to park() set: >>>> >>>> 5888 _cur_index = -1; >>>> >>>> Don't know if it's really possible, but... >>> >>> The code you refer to is all inside a critical region locked with the >>> mutex. No races possible. >>> >>> >>>>> With regard to assert versus assert_status - yes this would work: >>>>> >>>>> assert_status(status == 0, errno, "gettimeofday"); >>>>> >>>>> I had never considered that. :) When I added assert_status to diagnoze >>>>> a particular issue I never attempted to change all the existing >>>>> asserts on the library calls. So we have a lot of simple >>>>> "assert(status==0,"invariant") where assert_status could have been >>>>> used, as well as the old gettimeofday style calls. Do you want me to >>>>> change them all in os_linux.cpp? >>>> >>>> I guess that depends on whether we think this fix will need to be >>>> backported to HSX-24 or earlier... Less changes, the better, if a >>>> backport is in the future... >>> >>> Yes backports to 7 and 6 are definitely on the cards. The >>> assert/assert_status can be cleaned up as part of the big cleanup for 9 >>> (where a lot of the calls will disappear anyway as we get rid of all the >>> ancient workarounds). So I will leave this aspect as is. >>> >>> Thanks, >>> David >>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 13/09/2013 1:14 AM, Daniel D. Daugherty wrote: >>>>>> On 9/11/13 5:14 PM, David Holmes wrote: >>>>>>> updated webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v2/ >>>>>> >>>>>> Looks good. Possibly modulo one comment below... >>>>>> >>>>>> >>>>>>> On 12/09/2013 7:10 AM, Daniel D. Daugherty wrote: >>>>>>> >>>>>>>> line 5541: assert_status(status == 0, status, >>>>>>>> "clock_gettime"); >>>>>>>> line 5553: assert(status == 0, "gettimeofday"); >>>>>>>> So why is one an assert_status() call and the other is a >>>>>>>> plain old assert() call? >>>>>>> >>>>>>> Different API's. The old unix API's, like gettimeofday return -1 on >>>>>>> error and set errno. The "modern" posix APIs, eg pthread APIs and >>>>>>> clock_gettime etc, return the actual error code on error - hence >>>>>>> assert_status can be used to show the actual error in that case. >>>>>> >>>>>> I don't quite get what you're trying to say here. >>>>>> It seems that both calls are trying to verify >>>>>> that "status == 0". Or are you saying that: >>>>>> >>>>>> assert_status(status == 0, status, "gettimeofday"); >>>>>> >>>>>> is kind of a waste because "status" always be either "0" or "-1". >>>>>> So how about this: >>>>>> >>>>>> assert_status(status == 0, errno, "gettimeofday"); >>>>>> >>>>>> instead? That pattern should work to get more info. >>>>>> >>>>>> Dan >>>>>> >>>> >> >> > From david.holmes at oracle.com Fri Sep 13 16:42:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Sep 2013 09:42:27 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5233503A.8030607@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> <5232851B.3000103@oracle.com> <5233457B.4030307@oracle.com> <5233503A.8030607@oracle.com> Message-ID: <5233A2E3.2070408@oracle.com> On 14/09/2013 3:49 AM, Aleksey Shipilev wrote: > On 09/13/2013 09:03 PM, Daniel D. Daugherty wrote: >>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ >> >> I think you want to get some other eyes on this change. This is >> my fourth review and I'm not catching everything. Or I'm catching >> something, but not for exactly the right reasons. > > (Granted, I have mediocre experience with Linux APIs). > Nothing pops out for me. Thumbs up. Thanks Aleksey. > Stylistic: > "++absTime->tv_sec;" bothers me. There seems to be no reason to not to > use post-increment rather than let the readers infer what is being > incremented, and if the precedence rules play dirty here. Noted for future cleanup :) David > -Aleksey. > From stefan.karlsson at oracle.com Fri Sep 13 22:37:32 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 14 Sep 2013 07:37:32 +0200 Subject: Fwd: Review request: 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty In-Reply-To: <52322284.4000601@oracle.com> References: <523221AB.6040103@oracle.com> <52322284.4000601@oracle.com> Message-ID: <5233F61C.4050502@oracle.com> On 9/12/13 10:22 PM, Stefan Karlsson wrote: > Forwarding to hotspot-dev and bcc:ing hotspot-gc-dev, since this > change code that are shared between different HotSpot sub-components. > > StefanK > > -------- Original Message -------- > Subject: Review request: 8024752: Log TraceMetadata* output to > gclog_or_tty instead of tty > Date: Thu, 12 Sep 2013 22:18:51 +0200 > From: Stefan Karlsson > To: hotspot-gc-dev at openjdk.java.net > > > > http://cr.openjdk.java.net/~stefank/8024752/webrev.00 I moved the implementation of VirtualSpace::print() to virtualspace.cpp to get this to compile without precompiled headers. StefanK > > The output you get when turning on the TraceMetadata* flags end up in > different files. This makes these flags hard to use. > > The patch directs the output to the gclog_or_tty output stream. > > thanks, > StefanK > > From goetz.lindenmaier at sap.com Sun Sep 15 05:46:48 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 15 Sep 2013 12:46:48 +0000 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <52338FBB.2070308@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> <523110CC.1040307@oracle.com> <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> <52321DB0.1050103@oracle.com> <4295855A5C1DE049A61835A1887419CC0D02F11E@DEWDFEMB12A.global.corp.sap> <52338FBB.2070308@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D031476@DEWDFEMB12A.global.corp.sap> Hi, I am now using a constant as proposed by you, Vladimir. I like it much better this way. Here the new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg-3 Thanks for the review! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Saturday, September 14, 2013 12:21 AM To: Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. On 9/13/13 1:33 PM, Lindenmaier, Goetz wrote: > Hi, > >>> Why only intrinsify_fill changed? What about arraycopy and other stubs >>> which use int parameter? > I figured why we need the adaption of the signature for intrinsify_fill. > This stub call is done with a CallLeafNoFPNode, which is child of > CallRuntimeNode. Therefore the matcher expects c_calling_conventions. > Arraycopy stubs are called with CallStaticJavaNode, thus they are fine. Other stubs > just use 64-bit types. > Also there is a guarantee() in the ppc c_calling_convention() checking > the signature, so that we are sure we did not miss a case. Okay. > > I adapted the type test and moved the functions to the ppc file :( > What I don't like is that c_calling_convention_requires_ints_as_longs() can > not be inlined by the C Compiler. That's because sharedRuntime has > no platform header. Do you have an idea how I could improve this? Yes, if it was inlined we could keep those methods in shared code but their bodies will be guarded by c_calling_convention_requires_ints_as_longs() check and C will optimize them out on platforms we don't need them. May be replace c_calling_convention_requires_ints_as_longs() method with constant in globalDefinitions_.hpp ? Vladimir > http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg-2 > > Also, could I please get a second review? > > Thanks & best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, September 12, 2013 10:02 PM > To: Lindenmaier, Goetz > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. > > > > On 9/12/13 4:42 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp >>> to sharedRuntime_ppc.cpp? They are static and not used in any other places. >> I really would like to keep this code in the shared file because: >> - The code is completely plarform independent. >> - The feature needs several shared changes, so I think it's natural to keep all >> it's platform independent parts in the shared files. >> - Internally, we use it also for zArch, so for us it would reduce code duplication >> to have it in the shared file. > > My concern is about VM size on platforms which do not need this. > I wanted to suggest to put it under #ifdef but it will be ugly. > >> >>> Why only intrinsify_fill changed? What about arraycopy and other stubs >>> which use int parameter? >> Yes, that looks strange. For stub calls that should not be needed, as >> we also implement the callee. I'll investigate this in our VM, and try >> to remove the change to runtime.cpp and loopTransform.cpp. >> I'll come up with a new webrev then. Thanks for pointing me to this! >> >>> loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also >>> you can use (t == T_INT || is_subword_type(t)) check instead for int types. >> Above, a MoveF2I is issued, therefore ConvI2L works. Probably conversion >> is pointless, but the type is correct then. > > I missed MoveF2I. Okay then. > > Thanks, > Vladimir > >> >> Thanks for the review and for adapting the closed stuff to 0112. >> >> Best regards, >> Goetz. >> >> >> On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> This is the first of about 10 changes taking us to a rudimentary c2 >>> compiler on ppc64. >>> >>> Some platforms, as ppc and s390x/zArch require that 32-bit ints are >>> passed as 64-bit values to C functions. This change adds support to >>> adapt the signature and to issue proper casts to c2-compiled stubs. The >>> functions are used in generate_native_wrapper(). We also need to adapt >>> the signature in PhaseIdealLoop::intrinsify_fill(). >>> >>> We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with >>> >>> enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing >>> >>> platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by >>> >>> ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp >>> >>> line 1752 ff. >>> >>> >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ >>> >>> Please review and test this change. >>> >>> Best regards, >>> >>> Goetz. >>> From goetz.lindenmaier at sap.com Sun Sep 15 05:47:28 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 15 Sep 2013 12:47:28 +0000 Subject: RFR(S): 8024469: PPC64 (part 202): cppInterpreter: support for OSR. In-Reply-To: <52339013.2000306@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D030152@DEWDFEMB12A.global.corp.sap> <52339013.2000306@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D03148E@DEWDFEMB12A.global.corp.sap> Hi, Thanks a lot for the review. I pushed it. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Saturday, September 14, 2013 12:22 AM To: Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(S): 8024469: PPC64 (part 202): cppInterpreter: support for OSR. Good. I think you can push it yourself. thanks, Vladimir On 9/13/13 2:00 PM, Lindenmaier, Goetz wrote: > Hi, > > to do OSR with the cppInterpreter we need this small fix. > > http://cr.openjdk.java.net/~goetz/webrevs/8024469-osr > > The call to osr migration needs proper frame setup. > > Please review this change. > > Best regards, > > Goetz. > From goetz.lindenmaier at sap.com Sun Sep 15 06:58:17 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 15 Sep 2013 13:58:17 +0000 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling Message-ID: <4295855A5C1DE049A61835A1887419CC0D0324BD@DEWDFEMB12A.global.corp.sap> Hi, http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ this change implements bytecode profiling for the cppInterpreter. It changes a row of shared files, but most of the changes are guarded by CC_INTERP. This is not mandatory, but I think it makes clear what the extensions are meant for, and assures it's not compiled into template interpreter builds. We desinged the bytecode profiling for the cppInterpreter to deliver exact the same counter values as the template interpreter does. E.g., we extended the interpreter to also check backedge counts. The macros used in the interpreter loop are placed in a new file bytecodeInterpreterProfiling.hpp. I'm happy to move them somewhere else. The code is guarded with CC_INTERP_PROFILE, which is only enabled if COMPILER2 is set. Thus, ZERO will not encounter any overhead in the interpreter loop. This change also enables all the new features we implemented in the cppInterpreter, see arguments.cpp. Although this change is marked as L, it should not have an effect on non-cppInterpreter platforms. Please review and test this change. Best regards, Goetz. From coleen.phillimore at oracle.com Sun Sep 15 07:12:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Sun, 15 Sep 2013 10:12:45 -0400 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D0324BD@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D0324BD@DEWDFEMB12A.global.corp.sap> Message-ID: <5235C05D.5050304@oracle.com> Hi, This isn't a full review but can you refactor InterpreterRuntime::note_trap() so that there isn't duplicated code? It doesn't seem like there are enough differences for a separate function. Thanks, Coleen On 9/15/2013 9:58 AM, Lindenmaier, Goetz wrote: > Hi, > > http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ > this change implements bytecode profiling for the cppInterpreter. > It changes a row of shared files, but most of the changes are > guarded by CC_INTERP. This is not mandatory, but I think it > makes clear what the extensions are meant for, and assures it's > not compiled into template interpreter builds. > > We desinged the bytecode profiling for the cppInterpreter > to deliver exact the same counter values as the template interpreter does. > E.g., we extended the interpreter to also check backedge counts. > > The macros used in the interpreter loop are placed in a new > file bytecodeInterpreterProfiling.hpp. I'm happy to move them > somewhere else. > > The code is guarded with CC_INTERP_PROFILE, which is only enabled > if COMPILER2 is set. Thus, ZERO will not encounter any overhead > in the interpreter loop. > > This change also enables all the new features we implemented in > the cppInterpreter, see arguments.cpp. > > Although this change is marked as L, it should not have an effect > on non-cppInterpreter platforms. > > Please review and test this change. > > Best regards, > Goetz. From Alan.Bateman at oracle.com Sun Sep 15 08:05:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Sep 2013 16:05:26 +0100 Subject: Anything in hs25-b47 or b47 that would cause a significant performance regression? In-Reply-To: <5231A10B.7090109@oracle.com> References: <5231A10B.7090109@oracle.com> Message-ID: <5235CCB6.2040200@oracle.com> On 12/09/2013 12:10, Alan Bateman wrote: > > This is a long shot but does anyone know of any performance > regressions that might have crept in recently, specifically in > jdk8-b105 or jdk8-b106 (hs25-b47 or hs25-b48). > > jdk8/tl was sync'ed up to jdk8-b106 (it had been at b104) last Friday > and since then several of us have noticed significant slowdowns > (20-30%) in the time is takes to run the jdk tests. The jdk tests run > in agent VM mode that should mostly eliminate startup for most of the > tests. As jdk8/tl is always ahead of jdk8/jdk8 with library changes > then it means that the only interesting changes that the sync up > brought in is the HotSpot changes. > > I don't think anyone of has had the time to attempt to bisect this yet > (or know if this is all or only some OS/arch) and this mail is just to > see whether it rings any bells with anyone. > > -Alan > Just to follow up on this, it seems to be due to large pages, most likely the changes in JDK-8007074. Running with -XX:-UseLargePages restores the performance, at least on Linux x64 (Ubuntu 12.04LTS). -Alan. From francis.andre.kampbell at orange.fr Sun Sep 15 08:11:44 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sun, 15 Sep 2013 17:11:44 +0200 Subject: newbie: building the jvm.vsxproject on WXP/VS2010: HOW-TO Message-ID: <5235CE30.1050506@orange.fr> Hello I am trying to build the jvm.vsxproject on a WXP/VS2010 platform and I am wondering if there is any documentation of how-to about running create.bat and build.bat using the latest Cygwin toolset. Thanks for any pointer. FA From vladimir.kozlov at oracle.com Sun Sep 15 11:07:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 15 Sep 2013 11:07:01 -0700 Subject: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D031476@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D019F35@DEWDFEMB12A.global.corp.sap> <523110CC.1040307@oracle.com> <4295855A5C1DE049A61835A1887419CC0D026AA7@DEWDFEMB12A.global.corp.sap> <52321DB0.1050103@oracle.com> <4295855A5C1DE049A61835A1887419CC0D02F11E@DEWDFEMB12A.global.corp.sap> <52338FBB.2070308@oracle.com> <4295855A5C1DE049A61835A1887419CC0D031476@DEWDFEMB12A.global.corp.sap> Message-ID: <5235F745.1030508@oracle.com> It is good. I need to prepare closed part and I will push after its reviews. Thanks, Vladimir On 9/15/13 5:46 AM, Lindenmaier, Goetz wrote: > Hi, > > I am now using a constant as proposed by you, Vladimir. > I like it much better this way. Here the new webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg-3 > > Thanks for the review! > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Saturday, September 14, 2013 12:21 AM > To: Lindenmaier, Goetz > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. > > On 9/13/13 1:33 PM, Lindenmaier, Goetz wrote: >> Hi, >> >>>> Why only intrinsify_fill changed? What about arraycopy and other stubs >>>> which use int parameter? >> I figured why we need the adaption of the signature for intrinsify_fill. >> This stub call is done with a CallLeafNoFPNode, which is child of >> CallRuntimeNode. Therefore the matcher expects c_calling_conventions. >> Arraycopy stubs are called with CallStaticJavaNode, thus they are fine. Other stubs >> just use 64-bit types. >> Also there is a guarantee() in the ppc c_calling_convention() checking >> the signature, so that we are sure we did not miss a case. > > Okay. > >> >> I adapted the type test and moved the functions to the ppc file :( >> What I don't like is that c_calling_convention_requires_ints_as_longs() can >> not be inlined by the C Compiler. That's because sharedRuntime has >> no platform header. Do you have an idea how I could improve this? > > Yes, if it was inlined we could keep those methods in shared code but > their bodies will be guarded by > c_calling_convention_requires_ints_as_longs() check and C will optimize > them out on platforms we don't need them. > > May be replace c_calling_convention_requires_ints_as_longs() method with > constant in globalDefinitions_.hpp ? > > Vladimir > >> http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg-2 >> >> Also, could I please get a second review? >> >> Thanks & best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, September 12, 2013 10:02 PM >> To: Lindenmaier, Goetz >> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. >> >> >> >> On 9/12/13 4:42 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>>> Can you move convert_ints_to_longints*() methods from sharedRuntime.cpp >>>> to sharedRuntime_ppc.cpp? They are static and not used in any other places. >>> I really would like to keep this code in the shared file because: >>> - The code is completely plarform independent. >>> - The feature needs several shared changes, so I think it's natural to keep all >>> it's platform independent parts in the shared files. >>> - Internally, we use it also for zArch, so for us it would reduce code duplication >>> to have it in the shared file. >> >> My concern is about VM size on platforms which do not need this. >> I wanted to suggest to put it under #ifdef but it will be ugly. >> >>> >>>> Why only intrinsify_fill changed? What about arraycopy and other stubs >>>> which use int parameter? >>> Yes, that looks strange. For stub calls that should not be needed, as >>> we also implement the callee. I'll investigate this in our VM, and try >>> to remove the change to runtime.cpp and loopTransform.cpp. >>> I'll come up with a new webrev then. Thanks for pointing me to this! >>> >>>> loopTransform.cpp: I don't think ConvI2L will work for t==T_FLOAT. Also >>>> you can use (t == T_INT || is_subword_type(t)) check instead for int types. >>> Above, a MoveF2I is issued, therefore ConvI2L works. Probably conversion >>> is pointless, but the type is correct then. >> >> I missed MoveF2I. Okay then. >> >> Thanks, >> Vladimir >> >>> >>> Thanks for the review and for adapting the closed stuff to 0112. >>> >>> Best regards, >>> Goetz. >>> >>> >>> On 9/9/13 1:42 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> This is the first of about 10 changes taking us to a rudimentary c2 >>>> compiler on ppc64. >>>> >>>> Some platforms, as ppc and s390x/zArch require that 32-bit ints are >>>> passed as 64-bit values to C functions. This change adds support to >>>> adapt the signature and to issue proper casts to c2-compiled stubs. The >>>> functions are used in generate_native_wrapper(). We also need to adapt >>>> the signature in PhaseIdealLoop::intrinsify_fill(). >>>> >>>> We add a function c_calling_convention_requires_ints_as_longs()to the platform files of sharedRuntime, with >>>> >>>> enables this feature on ppc. All other shared changes depend on this function. The code should not affect the existing >>>> >>>> platforms. The usage of the code is already visible in the sharedRuntime_ppc64 file in the staging repository (protected by >>>> >>>> ifdef COMPILER2). Seehttp://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/file/bdd155477289/src/cpu/ppc/vm/sharedRuntime_ppc.cpp >>>> >>>> line 1752 ff. >>>> >>>> >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8024342-intArg/ >>>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> From goetz.lindenmaier at sap.com Sun Sep 15 14:19:46 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 15 Sep 2013 21:19:46 +0000 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <5235C05D.5050304@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D0324BD@DEWDFEMB12A.global.corp.sap> <5235C05D.5050304@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D032506@DEWDFEMB12A.global.corp.sap> Hi Coleen, thanks for the hint, I adapted the webrev. Looks better like that. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillmore Sent: Sunday, September 15, 2013 4:13 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling Hi, This isn't a full review but can you refactor InterpreterRuntime::note_trap() so that there isn't duplicated code? It doesn't seem like there are enough differences for a separate function. Thanks, Coleen On 9/15/2013 9:58 AM, Lindenmaier, Goetz wrote: > Hi, > > http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ > this change implements bytecode profiling for the cppInterpreter. > It changes a row of shared files, but most of the changes are > guarded by CC_INTERP. This is not mandatory, but I think it > makes clear what the extensions are meant for, and assures it's > not compiled into template interpreter builds. > > We desinged the bytecode profiling for the cppInterpreter > to deliver exact the same counter values as the template interpreter does. > E.g., we extended the interpreter to also check backedge counts. > > The macros used in the interpreter loop are placed in a new > file bytecodeInterpreterProfiling.hpp. I'm happy to move them > somewhere else. > > The code is guarded with CC_INTERP_PROFILE, which is only enabled > if COMPILER2 is set. Thus, ZERO will not encounter any overhead > in the interpreter loop. > > This change also enables all the new features we implemented in > the cppInterpreter, see arguments.cpp. > > Although this change is marked as L, it should not have an effect > on non-cppInterpreter platforms. > > Please review and test this change. > > Best regards, > Goetz. From david.holmes at oracle.com Sun Sep 15 18:41:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Sep 2013 11:41:18 +1000 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> Message-ID: <523661BE.9030302@oracle.com> On 14/09/2013 4:52 AM, Christian Tornqvist wrote: > I've added getCompileJDKTool() and getTestJDKTool(), the common function getJDKTool() will still look in test.jdk first and compile.jdk as a fallback. > > Changed the TestVerifyDuringStartup.java that Igor changed as part of his change to use getJDKTool() since this is what ProcessTools.createJavaProcessBuilder() does. > > Verified my change locally by running test/runtime and test/gc jtreg tests to verify that they work correctly when test.jdk is set to a JRE. > > New webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ Looks good to me! Thanks, Chris > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev-bounces at openjdk.java.net > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David > Holmes > Sent: Friday, September 13, 2013 7:11 AM > To: Erik Helin > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be > updated to divide test jdk and compile jdk > > Just to cc the list what I said in other email ... > > I think this is a good compromise. Having an API that allows the test to > select which JDK to use is important; but maintaining compatability with > existing test behaviour is also important. > > Thanks, > David > > On 12/09/2013 11:22 PM, Erik Helin wrote: >> On 2013-09-12, David Holmes wrote: >>> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>>> Christian, >>>>>>>> >>>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>>> JDK-8012447[*]: >>>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>>> >>>>>>>> So, I'm not sure that your change is necessary. >>>>>>> >>>>>>> I prefer Christian's approach as it is behaviour preserving. With >>>>>>> your change any test that actually wants/needs to use the test >>>>>>> JDK will have to be modified. >>>>>> I agree, but w/ Christian's approach we could get situation that >>>>>> we test binary from another JDK, e.g. >>>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>>> >>>>> I don't see how as the test JDK is checked first. The gap in >>>>> Christian's approach is the more rare case of where the test JDKs >>>>> tool must not be used for that part of the test. >>>> Oh sorry, I misread the code. Anyway, I don't think that this code >>>> is good, because if I want to get one of jdk tool, I expect that I >>>> will get it from '-compilejdk' if this option's specified, and from >>>> '-jdk', otherwise. But w/ Christian's patch I will get tool from >>>> '-jdk' if tool exists there, that may confuse. >>> >>> Anyone using this function has to know what it returns regardless of >>> whether that is from compile-jdk or test-jdk. With your change a >>> bunch of tests that were using the test-jdk tools will now be using >>> the compile-jdk tools, and while that might not cause a test failure >>> it might negate the purpose of the test. So unless you've examined >>> all the tests that use this API I can't agree that your change was >>> appropriate. >> >> I, Igor and Christian discussed this on IM and the solution that we >> came up with was that JDKToolFinder should have three methods: >> getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool should, >> as in Christian's change, first try to make use of getTestJDKTool and >> then, if that fails, use getCompilerJDKTool. >> >> getCompilerJDKTool and getTestJDKTool should be like the ones Igor has >> written, but the should use make use of a private function to avoid >> code duplication. >> >> This way, writing an simple test will still be easy, using getJDKTool >> should in most cases be what you want. However, if you are writing a >> more tricky test, getTestJDKTool and getCompilerJDKTool are still >> there for those cases. >> >> David, what do think about this suggestion? >> >>>>> So I think >>>>>> that any test that actually wants/needs to use the test JDK must >>>>>> do it explicitly. >>>>>>> >>>>>>>> [*] >>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33ff >>>>>>>> 54a3 >>>>>>> >>>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>>> hotspot-compiler-dev? >>>>>> >>>>>> It was reviewed only on hotspot-compiler-dev. >>>>> >>>>> These kinds of changes really have to be reviewed more broadly as >>>>> they affect everyone. We wouldn't even have known about your change >>>>> if Christian hadn't done this one. Plus the testlibrary really >>>>> should have a nominal owner to coordinate things - and we need to >>>>> make sure the hotspot and JDK versions are kept in sync. >> >> I guess that I and Christian usually try to monitor the changes to the >> hotspot testlibrary, and I think Igor will start do it as well :) This >> way, we at least have one from runtime, one from compiler and one from >> gc. >> >> As for keeping the JDK and HotSpot versions in sync, well that is a >> problem. One of the issues is that just because we in the hotspot team >> reviewed and approved changes to HotSpot's testlibrary does not >> automatically mean that the JDK team wants these patches. Therefore, >> keeping the JDK and the HotSpot test libraries in sync will require >> more work than just "moving patches". >> >> Unfortunately, I do not have any good solution for this at the moment >> :( >> >>>> I fully agree w/ you and I'm really sorry about the situation. >>>> But I don't see big difference between 'hotspot-runtime-dev' and >>>> 'hotspot-compiler-dev', so *this* change "really have to be reviewed >>>> more broadly as they affect everyone". >>> >>> I meant reviewing on hotspot-runtime-dev as well as >>> hotspot-compiler-dev, not in place of. hotspot-dev could have been in >>> place. >> >> I think hotspot-dev is better for changes to the hotspot testlibrary >> since the changes affect all the hotspot devevelopers. >> >> Thanks, >> Erik >> >>> Cheers, >>> David >>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Best regards, >>>>>>>> Igor Ignatyev >>>>>>>> >>>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02/ >>>>>>>>> >>>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Christian >>>>>>>>> > From david.holmes at oracle.com Sun Sep 15 18:45:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Sep 2013 11:45:11 +1000 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <523661BE.9030302@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> <523661BE.9030302@oracle.com> Message-ID: <523662A7.4010800@oracle.com> On 16/09/2013 11:41 AM, David Holmes wrote: > On 14/09/2013 4:52 AM, Christian Tornqvist wrote: >> I've added getCompileJDKTool() and getTestJDKTool(), the common >> function getJDKTool() will still look in test.jdk first and >> compile.jdk as a fallback. >> >> Changed the TestVerifyDuringStartup.java that Igor changed as part of >> his change to use getJDKTool() since this is what >> ProcessTools.createJavaProcessBuilder() does. >> >> Verified my change locally by running test/runtime and test/gc jtreg >> tests to verify that they work correctly when test.jdk is set to a JRE. >> >> New webrev can be found at: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ > > Looks good to me! > > Thanks, > Chris That should be: Thanks, Chris. David ----- David ----- :) >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-runtime-dev-bounces at openjdk.java.net >> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David >> Holmes >> Sent: Friday, September 13, 2013 7:11 AM >> To: Erik Helin >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be >> updated to divide test jdk and compile jdk >> >> Just to cc the list what I said in other email ... >> >> I think this is a good compromise. Having an API that allows the test to >> select which JDK to use is important; but maintaining compatability with >> existing test behaviour is also important. >> >> Thanks, >> David >> >> On 12/09/2013 11:22 PM, Erik Helin wrote: >>> On 2013-09-12, David Holmes wrote: >>>> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>>>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>>>> Christian, >>>>>>>>> >>>>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>>>> JDK-8012447[*]: >>>>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>>>> >>>>>>>>> So, I'm not sure that your change is necessary. >>>>>>>> >>>>>>>> I prefer Christian's approach as it is behaviour preserving. With >>>>>>>> your change any test that actually wants/needs to use the test >>>>>>>> JDK will have to be modified. >>>>>>> I agree, but w/ Christian's approach we could get situation that >>>>>>> we test binary from another JDK, e.g. >>>>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>>>> >>>>>> I don't see how as the test JDK is checked first. The gap in >>>>>> Christian's approach is the more rare case of where the test JDKs >>>>>> tool must not be used for that part of the test. >>>>> Oh sorry, I misread the code. Anyway, I don't think that this code >>>>> is good, because if I want to get one of jdk tool, I expect that I >>>>> will get it from '-compilejdk' if this option's specified, and from >>>>> '-jdk', otherwise. But w/ Christian's patch I will get tool from >>>>> '-jdk' if tool exists there, that may confuse. >>>> >>>> Anyone using this function has to know what it returns regardless of >>>> whether that is from compile-jdk or test-jdk. With your change a >>>> bunch of tests that were using the test-jdk tools will now be using >>>> the compile-jdk tools, and while that might not cause a test failure >>>> it might negate the purpose of the test. So unless you've examined >>>> all the tests that use this API I can't agree that your change was >>>> appropriate. >>> >>> I, Igor and Christian discussed this on IM and the solution that we >>> came up with was that JDKToolFinder should have three methods: >>> getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool should, >>> as in Christian's change, first try to make use of getTestJDKTool and >>> then, if that fails, use getCompilerJDKTool. >>> >>> getCompilerJDKTool and getTestJDKTool should be like the ones Igor has >>> written, but the should use make use of a private function to avoid >>> code duplication. >>> >>> This way, writing an simple test will still be easy, using getJDKTool >>> should in most cases be what you want. However, if you are writing a >>> more tricky test, getTestJDKTool and getCompilerJDKTool are still >>> there for those cases. >>> >>> David, what do think about this suggestion? >>> >>>>>> So I think >>>>>>> that any test that actually wants/needs to use the test JDK must >>>>>>> do it explicitly. >>>>>>>> >>>>>>>>> [*] >>>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33ff >>>>>>>>> 54a3 >>>>>>>> >>>>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>>>> hotspot-compiler-dev? >>>>>>> >>>>>>> It was reviewed only on hotspot-compiler-dev. >>>>>> >>>>>> These kinds of changes really have to be reviewed more broadly as >>>>>> they affect everyone. We wouldn't even have known about your change >>>>>> if Christian hadn't done this one. Plus the testlibrary really >>>>>> should have a nominal owner to coordinate things - and we need to >>>>>> make sure the hotspot and JDK versions are kept in sync. >>> >>> I guess that I and Christian usually try to monitor the changes to the >>> hotspot testlibrary, and I think Igor will start do it as well :) This >>> way, we at least have one from runtime, one from compiler and one from >>> gc. >>> >>> As for keeping the JDK and HotSpot versions in sync, well that is a >>> problem. One of the issues is that just because we in the hotspot team >>> reviewed and approved changes to HotSpot's testlibrary does not >>> automatically mean that the JDK team wants these patches. Therefore, >>> keeping the JDK and the HotSpot test libraries in sync will require >>> more work than just "moving patches". >>> >>> Unfortunately, I do not have any good solution for this at the moment >>> :( >>> >>>>> I fully agree w/ you and I'm really sorry about the situation. >>>>> But I don't see big difference between 'hotspot-runtime-dev' and >>>>> 'hotspot-compiler-dev', so *this* change "really have to be reviewed >>>>> more broadly as they affect everyone". >>>> >>>> I meant reviewing on hotspot-runtime-dev as well as >>>> hotspot-compiler-dev, not in place of. hotspot-dev could have been in >>>> place. >>> >>> I think hotspot-dev is better for changes to the hotspot testlibrary >>> since the changes affect all the hotspot devevelopers. >>> >>> Thanks, >>> Erik >>> >>>> Cheers, >>>> David >>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Igor Ignatyev >>>>>>>>> >>>>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02/ >>>>>>>>>> >>>>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Christian >>>>>>>>>> >> From dan at danny.cz Mon Sep 16 03:09:50 2013 From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=) Date: Mon, 16 Sep 2013 12:09:50 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp Message-ID: <20130916120950.2005303d0df54386b7c634a1@danny.cz> Hello, I've created a patch [1] to fix swapped usage of idx_t and bm_word_t types in hotspot/src/share/vm/utilities/bitMap.inline.hpp The code in hotspot/src/share/vm/utilities/bitMap.inline.hpp incorrectly swaps the usage of the idx_t and bm_word_t types. For most platforms these 2 types are effectively the same, so the interchange is uncaught, but on s390 (32-bit) the size_t is "unsigned long" which makes it incompatible with "unsigned int". The patch is result of my understanding of the logic inside bitMap.inline.hpp, so it needs definitely a review although I think I'm right :-) The same patch is used in our openjdk7 Fedora packages and the code compiles and works without issue on both s390 and s390x architectures there. from bitmap.hpp typedef size_t idx_t; // Type used for bit and word indices. typedef uintptr_t bm_word_t; // Element type of array that represents // the bitmap. [1] http://fedora.danny.cz/openjdk/bitmap/webrev/ Note: I'm Red Hat employee (dhorak at redhat.com), so I should be covered by Red Hat's CLA for my contributions. With regards Dan From coleen.phillimore at oracle.com Mon Sep 16 05:49:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Mon, 16 Sep 2013 08:49:06 -0400 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D032506@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D0324BD@DEWDFEMB12A.global.corp.sap> <5235C05D.5050304@oracle.com> <4295855A5C1DE049A61835A1887419CC0D032506@DEWDFEMB12A.global.corp.sap> Message-ID: <5236FE42.7040002@oracle.com> Yes, that does look better. Thanks! Coleen On 9/15/2013 5:19 PM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for the hint, I adapted the webrev. > Looks better like that. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillmore > Sent: Sunday, September 15, 2013 4:13 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling > > > Hi, > This isn't a full review but can you refactor > InterpreterRuntime::note_trap() so that there isn't duplicated code? > It doesn't seem like there are enough differences for a separate function. > > Thanks, > Coleen > > On 9/15/2013 9:58 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ >> this change implements bytecode profiling for the cppInterpreter. >> It changes a row of shared files, but most of the changes are >> guarded by CC_INTERP. This is not mandatory, but I think it >> makes clear what the extensions are meant for, and assures it's >> not compiled into template interpreter builds. >> >> We desinged the bytecode profiling for the cppInterpreter >> to deliver exact the same counter values as the template interpreter does. >> E.g., we extended the interpreter to also check backedge counts. >> >> The macros used in the interpreter loop are placed in a new >> file bytecodeInterpreterProfiling.hpp. I'm happy to move them >> somewhere else. >> >> The code is guarded with CC_INTERP_PROFILE, which is only enabled >> if COMPILER2 is set. Thus, ZERO will not encounter any overhead >> in the interpreter loop. >> >> This change also enables all the new features we implemented in >> the cppInterpreter, see arguments.cpp. >> >> Although this change is marked as L, it should not have an effect >> on non-cppInterpreter platforms. >> >> Please review and test this change. >> >> Best regards, >> Goetz. From christian.tornqvist at oracle.com Mon Sep 16 14:47:37 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 16 Sep 2013 17:47:37 -0400 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <523662A7.4010800@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> <523661BE.9030302@oracle.com> <523662A7.4010800@oracle.com> Message-ID: <007401ceb326$5c7c4420$1574cc60$@oracle.com> Updated webrev where I've removed runtime/NMT/MallocTestType.java runtime/NMT/ThreadedMallocTestType.java runtime/NMT/ThreadedVirtualAllocTestType.java runtime/NMT/VirtualAllocTestType.java runtime/NMT/BaselineWithParameter.java runtime/NMT/JcmdScale.java runtime/NMT/JcmdWithNMTDisabled.java runtime/NMT/ShutdownTwice.java runtime/NMT/SummaryAfterShutdown.java runtime/NMT/SummarySanityCheck.java runtime/RedefineObject/TestRedefineObject.java from the needs_jdk group in TEST.groups based on David's comment in the bug. Webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.04/ Thanks, Christian -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Sunday, September 15, 2013 9:45 PM To: Christian Tornqvist Cc: 'hotspot-dev developers' Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk On 16/09/2013 11:41 AM, David Holmes wrote: > On 14/09/2013 4:52 AM, Christian Tornqvist wrote: >> I've added getCompileJDKTool() and getTestJDKTool(), the common >> function getJDKTool() will still look in test.jdk first and >> compile.jdk as a fallback. >> >> Changed the TestVerifyDuringStartup.java that Igor changed as part of >> his change to use getJDKTool() since this is what >> ProcessTools.createJavaProcessBuilder() does. >> >> Verified my change locally by running test/runtime and test/gc jtreg >> tests to verify that they work correctly when test.jdk is set to a JRE. >> >> New webrev can be found at: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ > > Looks good to me! > > Thanks, > Chris That should be: Thanks, Chris. David ----- David ----- :) >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-runtime-dev-bounces at openjdk.java.net >> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of >> David Holmes >> Sent: Friday, September 13, 2013 7:11 AM >> To: Erik Helin >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be >> updated to divide test jdk and compile jdk >> >> Just to cc the list what I said in other email ... >> >> I think this is a good compromise. Having an API that allows the test >> to select which JDK to use is important; but maintaining >> compatability with existing test behaviour is also important. >> >> Thanks, >> David >> >> On 12/09/2013 11:22 PM, Erik Helin wrote: >>> On 2013-09-12, David Holmes wrote: >>>> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>>>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>>>> Christian, >>>>>>>>> >>>>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>>>> JDK-8012447[*]: >>>>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>>>> >>>>>>>>> So, I'm not sure that your change is necessary. >>>>>>>> >>>>>>>> I prefer Christian's approach as it is behaviour preserving. >>>>>>>> With your change any test that actually wants/needs to use the >>>>>>>> test JDK will have to be modified. >>>>>>> I agree, but w/ Christian's approach we could get situation that >>>>>>> we test binary from another JDK, e.g. >>>>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>>>> >>>>>> I don't see how as the test JDK is checked first. The gap in >>>>>> Christian's approach is the more rare case of where the test JDKs >>>>>> tool must not be used for that part of the test. >>>>> Oh sorry, I misread the code. Anyway, I don't think that this code >>>>> is good, because if I want to get one of jdk tool, I expect that I >>>>> will get it from '-compilejdk' if this option's specified, and >>>>> from '-jdk', otherwise. But w/ Christian's patch I will get tool >>>>> from '-jdk' if tool exists there, that may confuse. >>>> >>>> Anyone using this function has to know what it returns regardless >>>> of whether that is from compile-jdk or test-jdk. With your change a >>>> bunch of tests that were using the test-jdk tools will now be using >>>> the compile-jdk tools, and while that might not cause a test >>>> failure it might negate the purpose of the test. So unless you've >>>> examined all the tests that use this API I can't agree that your >>>> change was appropriate. >>> >>> I, Igor and Christian discussed this on IM and the solution that we >>> came up with was that JDKToolFinder should have three methods: >>> getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool >>> should, as in Christian's change, first try to make use of >>> getTestJDKTool and then, if that fails, use getCompilerJDKTool. >>> >>> getCompilerJDKTool and getTestJDKTool should be like the ones Igor >>> has written, but the should use make use of a private function to >>> avoid code duplication. >>> >>> This way, writing an simple test will still be easy, using >>> getJDKTool should in most cases be what you want. However, if you >>> are writing a more tricky test, getTestJDKTool and >>> getCompilerJDKTool are still there for those cases. >>> >>> David, what do think about this suggestion? >>> >>>>>> So I think >>>>>>> that any test that actually wants/needs to use the test JDK must >>>>>>> do it explicitly. >>>>>>>> >>>>>>>>> [*] >>>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33 >>>>>>>>> ff >>>>>>>>> 54a3 >>>>>>>> >>>>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>>>> hotspot-compiler-dev? >>>>>>> >>>>>>> It was reviewed only on hotspot-compiler-dev. >>>>>> >>>>>> These kinds of changes really have to be reviewed more broadly as >>>>>> they affect everyone. We wouldn't even have known about your >>>>>> change if Christian hadn't done this one. Plus the testlibrary >>>>>> really should have a nominal owner to coordinate things - and we >>>>>> need to make sure the hotspot and JDK versions are kept in sync. >>> >>> I guess that I and Christian usually try to monitor the changes to >>> the hotspot testlibrary, and I think Igor will start do it as well >>> :) This way, we at least have one from runtime, one from compiler >>> and one from gc. >>> >>> As for keeping the JDK and HotSpot versions in sync, well that is a >>> problem. One of the issues is that just because we in the hotspot >>> team reviewed and approved changes to HotSpot's testlibrary does not >>> automatically mean that the JDK team wants these patches. Therefore, >>> keeping the JDK and the HotSpot test libraries in sync will require >>> more work than just "moving patches". >>> >>> Unfortunately, I do not have any good solution for this at the >>> moment :( >>> >>>>> I fully agree w/ you and I'm really sorry about the situation. >>>>> But I don't see big difference between 'hotspot-runtime-dev' and >>>>> 'hotspot-compiler-dev', so *this* change "really have to be >>>>> reviewed more broadly as they affect everyone". >>>> >>>> I meant reviewing on hotspot-runtime-dev as well as >>>> hotspot-compiler-dev, not in place of. hotspot-dev could have been >>>> in place. >>> >>> I think hotspot-dev is better for changes to the hotspot testlibrary >>> since the changes affect all the hotspot devevelopers. >>> >>> Thanks, >>> Erik >>> >>>> Cheers, >>>> David >>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Igor Ignatyev >>>>>>>>> >>>>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02 >>>>>>>>>> / >>>>>>>>>> >>>>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Christian >>>>>>>>>> >> From jon.masamitsu at oracle.com Mon Sep 16 17:08:44 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 16 Sep 2013 17:08:44 -0700 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <5232FD45.1030208@oracle.com> References: <5231DB36.6080101@oracle.com> <5232FD45.1030208@oracle.com> Message-ID: <52379D8C.6010609@oracle.com> To follow up on Thomas' point about 90 if (MetaspaceSize < 256*K) { 91 vm_exit_during_initialization("Too small initial Metaspace size"); 92 } There really isn't a value of MetaspaceSize that is too small. It is just a high-water-mark. If it was zero, it should still work (just would get a GC sooner rather than later). I haven't tried it (hit the assertion) but it should work. I'll file a bug if you don't want to include it with this. Jon On 9/13/2013 4:55 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8024650/webrev.01/ > > Changed in this revision: > - Removed incorrect FLAG_IS_DEFAULT check > - Added MetaspaceSize <= MaxMetaspaceSize assert > - Added boundary test cases where MetaspaceSize and MaxMetaspaceSize > is set to 0. > - Added rudimentary tests for the new firstMatch function. > > Rejected proposals: > - Use MXBeans to get flag values. > - Use WBApi to get conservative max heap alignment. > > thanks, > StefanK > > > On 09/12/2013 05:18 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ >> >> - Limit MetaspaceSize to MaxMetaspaceSize >> - Make sure we don't align down to 0. >> - jtreg test >> >> Note that this patch also adds/changes some functionality in the >> OutputAnalyzer in test/testlibrary. >> >> thanks, >> StefanK > From mike.duigou at oracle.com Mon Sep 16 17:16:42 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 16 Sep 2013 17:16:42 -0700 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" Message-ID: Hello all; This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired. http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person). Mike From vladimir.kozlov at oracle.com Mon Sep 16 17:29:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 16 Sep 2013 17:29:07 -0700 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: References: Message-ID: <5237A253.4060705@oracle.com> Looks good. Both. I assume you will send webrev for closed changes. Thanks, Vladimir PS: RIP jbb2005 ;) On 9/16/13 5:16 PM, Mike Duigou wrote: > Hello all; > > This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. > > Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired. > > http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ > > Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person). > > Mike > From david.holmes at oracle.com Mon Sep 16 19:37:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 12:37:19 +1000 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: References: Message-ID: <5237C05F.9050506@oracle.com> Reviewed both hotspot and jdk changes. Thumbs up and good riddance! :) How do you propose to handle the coordination of the push? Thanks, David On 17/09/2013 10:16 AM, Mike Duigou wrote: > Hello all; > > This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. > > Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired. > > http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ > > Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person). > > Mike > From david.holmes at oracle.com Mon Sep 16 19:41:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 12:41:54 +1000 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <007401ceb326$5c7c4420$1574cc60$@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> <523661BE.9030302@oracle.com> <523662A7.4010800@oracle.com> <007401ceb326$5c7c4420$1574cc60$@oracle.com> Message-ID: <5237C172.5000209@oracle.com> Thumbs up from me! Thanks, David On 17/09/2013 7:47 AM, Christian Tornqvist wrote: > Updated webrev where I've removed > > runtime/NMT/MallocTestType.java > runtime/NMT/ThreadedMallocTestType.java > runtime/NMT/ThreadedVirtualAllocTestType.java > runtime/NMT/VirtualAllocTestType.java > runtime/NMT/BaselineWithParameter.java > runtime/NMT/JcmdScale.java > runtime/NMT/JcmdWithNMTDisabled.java > runtime/NMT/ShutdownTwice.java > runtime/NMT/SummaryAfterShutdown.java > runtime/NMT/SummarySanityCheck.java > runtime/RedefineObject/TestRedefineObject.java > > from the needs_jdk group in TEST.groups based on David's comment in the bug. > > Webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.04/ > > Thanks, > Christian > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Sunday, September 15, 2013 9:45 PM > To: Christian Tornqvist > Cc: 'hotspot-dev developers' > Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk > > On 16/09/2013 11:41 AM, David Holmes wrote: >> On 14/09/2013 4:52 AM, Christian Tornqvist wrote: >>> I've added getCompileJDKTool() and getTestJDKTool(), the common >>> function getJDKTool() will still look in test.jdk first and >>> compile.jdk as a fallback. >>> >>> Changed the TestVerifyDuringStartup.java that Igor changed as part of >>> his change to use getJDKTool() since this is what >>> ProcessTools.createJavaProcessBuilder() does. >>> >>> Verified my change locally by running test/runtime and test/gc jtreg >>> tests to verify that they work correctly when test.jdk is set to a JRE. >>> >>> New webrev can be found at: >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ >> >> Looks good to me! >> >> Thanks, >> Chris > > That should be: > > Thanks, Chris. > > David > ----- > > David > ----- > > :) > >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: hotspot-runtime-dev-bounces at openjdk.java.net >>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of >>> David Holmes >>> Sent: Friday, September 13, 2013 7:11 AM >>> To: Erik Helin >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be >>> updated to divide test jdk and compile jdk >>> >>> Just to cc the list what I said in other email ... >>> >>> I think this is a good compromise. Having an API that allows the test >>> to select which JDK to use is important; but maintaining >>> compatability with existing test behaviour is also important. >>> >>> Thanks, >>> David >>> >>> On 12/09/2013 11:22 PM, Erik Helin wrote: >>>> On 2013-09-12, David Holmes wrote: >>>>> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>>>>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>>>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>>>>> Christian, >>>>>>>>>> >>>>>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>>>>> JDK-8012447[*]: >>>>>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>>>>> >>>>>>>>>> So, I'm not sure that your change is necessary. >>>>>>>>> >>>>>>>>> I prefer Christian's approach as it is behaviour preserving. >>>>>>>>> With your change any test that actually wants/needs to use the >>>>>>>>> test JDK will have to be modified. >>>>>>>> I agree, but w/ Christian's approach we could get situation that >>>>>>>> we test binary from another JDK, e.g. >>>>>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>>>>> >>>>>>> I don't see how as the test JDK is checked first. The gap in >>>>>>> Christian's approach is the more rare case of where the test JDKs >>>>>>> tool must not be used for that part of the test. >>>>>> Oh sorry, I misread the code. Anyway, I don't think that this code >>>>>> is good, because if I want to get one of jdk tool, I expect that I >>>>>> will get it from '-compilejdk' if this option's specified, and >>>>>> from '-jdk', otherwise. But w/ Christian's patch I will get tool >>>>>> from '-jdk' if tool exists there, that may confuse. >>>>> >>>>> Anyone using this function has to know what it returns regardless >>>>> of whether that is from compile-jdk or test-jdk. With your change a >>>>> bunch of tests that were using the test-jdk tools will now be using >>>>> the compile-jdk tools, and while that might not cause a test >>>>> failure it might negate the purpose of the test. So unless you've >>>>> examined all the tests that use this API I can't agree that your >>>>> change was appropriate. >>>> >>>> I, Igor and Christian discussed this on IM and the solution that we >>>> came up with was that JDKToolFinder should have three methods: >>>> getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool >>>> should, as in Christian's change, first try to make use of >>>> getTestJDKTool and then, if that fails, use getCompilerJDKTool. >>>> >>>> getCompilerJDKTool and getTestJDKTool should be like the ones Igor >>>> has written, but the should use make use of a private function to >>>> avoid code duplication. >>>> >>>> This way, writing an simple test will still be easy, using >>>> getJDKTool should in most cases be what you want. However, if you >>>> are writing a more tricky test, getTestJDKTool and >>>> getCompilerJDKTool are still there for those cases. >>>> >>>> David, what do think about this suggestion? >>>> >>>>>>> So I think >>>>>>>> that any test that actually wants/needs to use the test JDK must >>>>>>>> do it explicitly. >>>>>>>>> >>>>>>>>>> [*] >>>>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33 >>>>>>>>>> ff >>>>>>>>>> 54a3 >>>>>>>>> >>>>>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>>>>> hotspot-compiler-dev? >>>>>>>> >>>>>>>> It was reviewed only on hotspot-compiler-dev. >>>>>>> >>>>>>> These kinds of changes really have to be reviewed more broadly as >>>>>>> they affect everyone. We wouldn't even have known about your >>>>>>> change if Christian hadn't done this one. Plus the testlibrary >>>>>>> really should have a nominal owner to coordinate things - and we >>>>>>> need to make sure the hotspot and JDK versions are kept in sync. >>>> >>>> I guess that I and Christian usually try to monitor the changes to >>>> the hotspot testlibrary, and I think Igor will start do it as well >>>> :) This way, we at least have one from runtime, one from compiler >>>> and one from gc. >>>> >>>> As for keeping the JDK and HotSpot versions in sync, well that is a >>>> problem. One of the issues is that just because we in the hotspot >>>> team reviewed and approved changes to HotSpot's testlibrary does not >>>> automatically mean that the JDK team wants these patches. Therefore, >>>> keeping the JDK and the HotSpot test libraries in sync will require >>>> more work than just "moving patches". >>>> >>>> Unfortunately, I do not have any good solution for this at the >>>> moment :( >>>> >>>>>> I fully agree w/ you and I'm really sorry about the situation. >>>>>> But I don't see big difference between 'hotspot-runtime-dev' and >>>>>> 'hotspot-compiler-dev', so *this* change "really have to be >>>>>> reviewed more broadly as they affect everyone". >>>>> >>>>> I meant reviewing on hotspot-runtime-dev as well as >>>>> hotspot-compiler-dev, not in place of. hotspot-dev could have been >>>>> in place. >>>> >>>> I think hotspot-dev is better for changes to the hotspot testlibrary >>>> since the changes affect all the hotspot devevelopers. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Cheers, >>>>> David >>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Igor Ignatyev >>>>>>>>>> >>>>>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>>>>> Hi everyone, >>>>>>>>>>> >>>>>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02 >>>>>>>>>>> / >>>>>>>>>>> >>>>>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Christian >>>>>>>>>>> >>> > From mike.duigou at oracle.com Mon Sep 16 20:24:03 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 16 Sep 2013 20:24:03 -0700 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: <5237C05F.9050506@oracle.com> References: <5237C05F.9050506@oracle.com> Message-ID: <5E37DE88-F850-41BB-BDCF-0D24C4C33EFC@oracle.com> On Sep 16 2013, at 19:37 , David Holmes wrote: > Reviewed both hotspot and jdk changes. > > Thumbs up and good riddance! :) > > How do you propose to handle the coordination of the push? The hotspot and jdk changes can go in any order. I plan to push them sequential after cross platform test build along with the closed source portion. The closed portion has to happen after the open jdk repo makefile changes. Mike > > Thanks, > David > > On 17/09/2013 10:16 AM, Mike Duigou wrote: >> Hello all; >> >> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. >> >> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ >> >> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person). >> >> Mike >> From stefan.karlsson at oracle.com Mon Sep 16 22:05:55 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 17 Sep 2013 07:05:55 +0200 Subject: Review request: 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize In-Reply-To: <52379D8C.6010609@oracle.com> References: <5231DB36.6080101@oracle.com> <5232FD45.1030208@oracle.com> <52379D8C.6010609@oracle.com> Message-ID: <5237E333.6000500@oracle.com> On 9/17/13 2:08 AM, Jon Masamitsu wrote: > To follow up on Thomas' point about > > 90 if (MetaspaceSize < 256*K) { > 91 vm_exit_during_initialization("Too small initial Metaspace > size"); > 92 } > > There really isn't a value of MetaspaceSize that is too small. It is > just > a high-water-mark. If it was zero, it should still work (just would get > a GC sooner rather than later). I haven't tried it (hit the > assertion) but it should work. I'll file a bug if you don't want to > include > it with this. I've already pushed the fix for 8024650, so we would need a new bug report for that. Related to this is the alignment of MetaspaceSize and MaxMetaspaeSize. It's done with min_alignment() and max_alignment(). These are the wrong alignments, since we don't have the same restrictions on the metaspaces as Java Heap has. We should be aligning to the memory commit granularity. StefanK > > Jon > > > On 9/13/2013 4:55 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8024650/webrev.01/ >> >> Changed in this revision: >> - Removed incorrect FLAG_IS_DEFAULT check >> - Added MetaspaceSize <= MaxMetaspaceSize assert >> - Added boundary test cases where MetaspaceSize and MaxMetaspaceSize >> is set to 0. >> - Added rudimentary tests for the new firstMatch function. >> >> Rejected proposals: >> - Use MXBeans to get flag values. >> - Use WBApi to get conservative max heap alignment. >> >> thanks, >> StefanK >> >> >> On 09/12/2013 05:18 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8024650/webrev.00/ >>> >>> - Limit MetaspaceSize to MaxMetaspaceSize >>> - Make sure we don't align down to 0. >>> - jtreg test >>> >>> Note that this patch also adds/changes some functionality in the >>> OutputAnalyzer in test/testlibrary. >>> >>> thanks, >>> StefanK >> > From david.holmes at oracle.com Mon Sep 16 22:31:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 15:31:52 +1000 Subject: RFR: 6900441 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock In-Reply-To: <5233A2E3.2070408@oracle.com> References: <52304EB5.7000603@oracle.com> <5230DC2D.1020204@oracle.com> <5230F96A.30306@oracle.com> <5231DA5E.9070102@oracle.com> <52323674.6060709@oracle.com> <52324EAA.40806@oracle.com> <5232636A.7070702@oracle.com> <5232851B.3000103@oracle.com> <5233457B.4030307@oracle.com> <5233503A.8030607@oracle.com> <5233A2E3.2070408@oracle.com> Message-ID: <5237E948.2070104@oracle.com> This fix has been pushed to hs25 for JDK 8. For the record testing involved some specific time-jump tests attached to the bug report (and further variants to test parkNanos and parkUntil); the java/util/concurrent jtreg tests; the jcstress concurrency stress tests and the regular JPRT tests. David On 14/09/2013 9:42 AM, David Holmes wrote: > On 14/09/2013 3:49 AM, Aleksey Shipilev wrote: >> On 09/13/2013 09:03 PM, Daniel D. Daugherty wrote: >>>> http://cr.openjdk.java.net/~dholmes/6900441/webrev.v4/ >>> >>> I think you want to get some other eyes on this change. This is >>> my fourth review and I'm not catching everything. Or I'm catching >>> something, but not for exactly the right reasons. >> >> (Granted, I have mediocre experience with Linux APIs). >> Nothing pops out for me. Thumbs up. > > Thanks Aleksey. > >> Stylistic: >> "++absTime->tv_sec;" bothers me. There seems to be no reason to not to >> use post-increment rather than let the readers infer what is being >> incremented, and if the precedence rules play dirty here. > > Noted for future cleanup :) > > David > >> -Aleksey. >> From Alan.Bateman at oracle.com Tue Sep 17 00:01:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Sep 2013 08:01:41 +0100 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: References: Message-ID: <5237FE55.1070407@oracle.com> On 17/09/2013 01:16, Mike Duigou wrote: > Hello all; > > This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. > > Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired. > > http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ > > Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person). > > Mike Thank you Mike, looks like you've caught everything and it's great to finally get rid of this. -Alan. From david.holmes at oracle.com Tue Sep 17 00:21:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 17:21:01 +1000 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: <5237C05F.9050506@oracle.com> References: <5237C05F.9050506@oracle.com> Message-ID: <523802DD.3020709@oracle.com> Hi Mike, Looks like there is one test that knows it has to exercise the alt-rt.jar version: ./java/util/TreeMap/Clone.java * @run main/othervm Clone * @run main/othervm -XX:+AggressiveOpts Clone but it's harmless to leave the second invocation. I didn't see anything in JDK or hotspot regression tests that would be impacted. Once you are ready I will sponsor the hotspot patch for you through hotspot-rt. Thanks, David On 17/09/2013 12:37 PM, David Holmes wrote: > Reviewed both hotspot and jdk changes. > > Thumbs up and good riddance! :) > > How do you propose to handle the coordination of the push? > > Thanks, > David > > On 17/09/2013 10:16 AM, Mike Duigou wrote: >> Hello all; >> >> This is a cross-repo patch which disables building and enabling of the >> alt-rt.jar file. The alt-rt.jar file has been used with the >> -XX:+AggressiveOpts option (which will be remaining for other >> optimizations). This jar file formerly contained (closed-source) >> versions of several JDK classes which were optimized for very specific >> workloads. The implementations weren't generally applicable and in >> many cases induced performance drops. In particular since we will not >> be providing optimized implementations of the Java 8 streams API for >> the alternate versions of these classes the performance relative to >> the standard implementations would be poor. >> >> Over time we've (largely Alan Bateman) been trying to eliminate this >> difficult to support feature. With this changeset the alt-rt.jar >> feature is retired. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ >> >> Ideally I would like a reviewer for both the HotSpot and JDK repos >> (could be the same person). >> >> Mike >> From thomas.schatzl at oracle.com Tue Sep 17 01:27:10 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Sep 2013 10:27:10 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <20130916120950.2005303d0df54386b7c634a1@danny.cz> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> Message-ID: <1379406430.2702.19.camel@cirrus> Hi, On Mon, 2013-09-16 at 12:09 +0200, Dan Hor?k wrote: > Hello, > > I've created a patch [1] to fix swapped usage of idx_t and bm_word_t > types in hotspot/src/share/vm/utilities/bitMap.inline.hpp > > The code in hotspot/src/share/vm/utilities/bitMap.inline.hpp > incorrectly swaps the usage of the idx_t and bm_word_t types. For most > platforms these 2 types are effectively the same, so the interchange is > uncaught, but on s390 (32-bit) the size_t is "unsigned long" which > makes it incompatible with "unsigned int". The patch is result of my > understanding of the logic inside bitMap.inline.hpp, so it needs > definitely a review although I think I'm right :-) The same patch is > used in our openjdk7 Fedora packages and the code compiles and works > without issue on both s390 and s390x architectures there. > > from bitmap.hpp > > typedef size_t idx_t; // Type used for bit and word indices. > typedef uintptr_t bm_word_t; // Element type of array that represents > // the bitmap. > > > [1] http://fedora.danny.cz/openjdk/bitmap/webrev/ I created the bug JDK-8024914 ( https://bugs.openjdk.java.net/browse/JDK-8024914) - the bug tracker is publicly open now to track this btw. Looks good to me. Need a review from a Reviewer still though. I can shepherd it further after that. Thanks for your contribution, Thomas From chris.hegarty at oracle.com Tue Sep 17 01:36:55 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Sep 2013 09:36:55 +0100 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: <5E37DE88-F850-41BB-BDCF-0D24C4C33EFC@oracle.com> References: <5237C05F.9050506@oracle.com> <5E37DE88-F850-41BB-BDCF-0D24C4C33EFC@oracle.com> Message-ID: <523814A7.5080903@oracle.com> The changes look fine to me too. With such a trivial change to hotspot it may be possible to push this through TL? Trivially, and separate to this change, I can see further cleanup opportunities [1], as well as some tests that ref alt-rt.jar [2] [3]. Not that I really care (but I know others do), will the old build still work after these changes? -Chris. [1] http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1b7f5a27c4ba/src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java (L99) [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1b7f5a27c4ba/test/tools/javac/processing/model/testgetallmembers/Main.java (L136) [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/b67c8099ba28/test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java (L228) On 09/17/2013 04:24 AM, Mike Duigou wrote: > > On Sep 16 2013, at 19:37 , David Holmes wrote: > >> Reviewed both hotspot and jdk changes. >> >> Thumbs up and good riddance! :) >> >> How do you propose to handle the coordination of the push? > > The hotspot and jdk changes can go in any order. I plan to push them sequential after cross platform test build along with the closed source portion. The closed portion has to happen after the open jdk repo makefile changes. > > Mike > >> >> Thanks, >> David >> >> On 17/09/2013 10:16 AM, Mike Duigou wrote: >>> Hello all; >>> >>> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. >>> >>> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ >>> >>> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person). >>> >>> Mike >>> > From aleksey.shipilev at oracle.com Tue Sep 17 01:43:04 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 Sep 2013 12:43:04 +0400 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: References: Message-ID: <52381618.6080709@oracle.com> On 09/17/2013 04:16 AM, Mike Duigou wrote: > http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ I, for one who is responsible for eliminating the need for alt-rt.jar, greatly applaud this change. -Aleksey. From bengt.rutisson at oracle.com Tue Sep 17 02:48:20 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 17 Sep 2013 11:48:20 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <1379406430.2702.19.camel@cirrus> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> Message-ID: <52382564.3060709@oracle.com> Hello Dan and Thomas, The change looks good to me to. Thanks for finding and fixing this! Bengt On 9/17/13 10:27 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2013-09-16 at 12:09 +0200, Dan Hor?k wrote: >> Hello, >> >> I've created a patch [1] to fix swapped usage of idx_t and bm_word_t >> types in hotspot/src/share/vm/utilities/bitMap.inline.hpp >> >> The code in hotspot/src/share/vm/utilities/bitMap.inline.hpp >> incorrectly swaps the usage of the idx_t and bm_word_t types. For most >> platforms these 2 types are effectively the same, so the interchange is >> uncaught, but on s390 (32-bit) the size_t is "unsigned long" which >> makes it incompatible with "unsigned int". The patch is result of my >> understanding of the logic inside bitMap.inline.hpp, so it needs >> definitely a review although I think I'm right :-) The same patch is >> used in our openjdk7 Fedora packages and the code compiles and works >> without issue on both s390 and s390x architectures there. >> >> from bitmap.hpp >> >> typedef size_t idx_t; // Type used for bit and word indices. >> typedef uintptr_t bm_word_t; // Element type of array that represents >> // the bitmap. >> >> >> [1] http://fedora.danny.cz/openjdk/bitmap/webrev/ > I created the bug JDK-8024914 ( > https://bugs.openjdk.java.net/browse/JDK-8024914) - the bug tracker is > publicly open now to track this btw. > > Looks good to me. Need a review from a Reviewer still though. I can > shepherd it further after that. > > Thanks for your contribution, > Thomas > > From thomas.schatzl at oracle.com Tue Sep 17 03:39:22 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Sep 2013 12:39:22 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <52382564.3060709@oracle.com> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> <52382564.3060709@oracle.com> Message-ID: <1379414362.2702.39.camel@cirrus> Hi Bengt, On Tue, 2013-09-17 at 11:48 +0200, Bengt Rutisson wrote: > Hello Dan and Thomas, > > The change looks good to me to. Thanks for finding and fixing this! > Thanks for the quick review. @Dan: The patch is now in the push queue and will go through the hotspot-gc mercurial tree. Thomas From erik.helin at oracle.com Tue Sep 17 04:48:18 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 17 Sep 2013 13:48:18 +0200 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data In-Reply-To: <5232F1F0.3090302@oracle.com> References: <20130912214601.GC4100@ehelin-thinkpad> <5232F1F0.3090302@oracle.com> Message-ID: <20130917114818.GD2261@ehelin-thinkpad> On 2013-09-13, David Holmes wrote: > Hi Erik, > Just looking at the tests ... Hi David, thanks for reviewing the tests! On 2013-09-13, David Holmes wrote: > Can you please add -XX:+UsePerfData to the @run lines of the new test. Done. On 2013-09-13, David Holmes wrote: > Have you discussed the change to InputArguments.contains? I'm the one who added the class InputArguments to testlibrary and I'm also the only one that have been using it so far when writing tests :) However, I have CC:d Christian and Igor on this email, if they have an opinion on this. On 2013-09-13, David Holmes wrote: > If we have any args that are substrings of other args then this change > will cause incorrect matching. I actually do not know if any flag is a substring of any other flag, but you are right that it could potentially be confusing. On 2013-09-13, David Holmes wrote: > Would it not be better to add a new function that checks the prefix > rather than the whole arg? Agree. I suggest the following two methods: - InputArguments.contains, works the same way as today - InputArguments.containsPrefix, checks if one of the arguments contains the given prefix I've uploaded a new webrev at: http://cr.openjdk.java.net/~ehelin/8024718/webrev.01/ What do you think? Thanks, Erik > Thanks, > David > > On 13/09/2013 7:46 AM, Erik Helin wrote: > >Hi all, > > > >this patch fixes some issues with memory pools and the performance > >counter reporting slightly different numbers for metaspace. I've also > >updated two jtreg tests as well as added a new one to test the change. > > > >InputArguments.java in the testlibrary is updated as well. > >InputArguments.contains now takes a prefix as a parameter instead of the > >exact name of a flag. This makes it possible to check if a flag expecting > >a value has been set. For example, -XX:MaxMetaspaceSize=100m can be > >checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ > > > >Testing: > >- JPRT > >- hotspot/test/gc (including updated and new tests) > > > >Thanks, > >Erik > > From david.holmes at oracle.com Tue Sep 17 04:56:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 21:56:51 +1000 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data In-Reply-To: <20130917114818.GD2261@ehelin-thinkpad> References: <20130912214601.GC4100@ehelin-thinkpad> <5232F1F0.3090302@oracle.com> <20130917114818.GD2261@ehelin-thinkpad> Message-ID: <52384383.1070800@oracle.com> On 17/09/2013 9:48 PM, Erik Helin wrote: > On 2013-09-13, David Holmes wrote: >> Hi Erik, >> Just looking at the tests ... > > Hi David, > thanks for reviewing the tests! > > On 2013-09-13, David Holmes wrote: >> Can you please add -XX:+UsePerfData to the @run lines of the new test. > > Done. Thanks. > On 2013-09-13, David Holmes wrote: >> Have you discussed the change to InputArguments.contains? > > I'm the one who added the class InputArguments to testlibrary and I'm > also the only one that have been using it so far when writing tests :) > > However, I have CC:d Christian and Igor on this email, if they have an > opinion on this. > > On 2013-09-13, David Holmes wrote: >> If we have any args that are substrings of other args then this change >> will cause incorrect matching. > > I actually do not know if any flag is a substring of any other flag, but > you are right that it could potentially be confusing. There are many, many VM options that are substrings. A few examples: PrintAssembly PrintAssemblyOptions PrintCFG PrintCFG0 PrintCFG1 PrintGC PrintGCDetails > On 2013-09-13, David Holmes wrote: >> Would it not be better to add a new function that checks the prefix >> rather than the whole arg? > > Agree. I suggest the following two methods: > - InputArguments.contains, works the same way as today > - InputArguments.containsPrefix, checks if one of the arguments contains > the given prefix > > I've uploaded a new webrev at: > http://cr.openjdk.java.net/~ehelin/8024718/webrev.01/ > > What do you think? That works for me - the InputArguments part that is. Thanks, David > Thanks, > Erik > >> Thanks, >> David >> >> On 13/09/2013 7:46 AM, Erik Helin wrote: >>> Hi all, >>> >>> this patch fixes some issues with memory pools and the performance >>> counter reporting slightly different numbers for metaspace. I've also >>> updated two jtreg tests as well as added a new one to test the change. >>> >>> InputArguments.java in the testlibrary is updated as well. >>> InputArguments.contains now takes a prefix as a parameter instead of the >>> exact name of a flag. This makes it possible to check if a flag expecting >>> a value has been set. For example, -XX:MaxMetaspaceSize=100m can be >>> checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ >>> >>> Testing: >>> - JPRT >>> - hotspot/test/gc (including updated and new tests) >>> >>> Thanks, >>> Erik >>> From dan at danny.cz Tue Sep 17 05:17:09 2013 From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=) Date: Tue, 17 Sep 2013 14:17:09 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <1379414362.2702.39.camel@cirrus> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> <52382564.3060709@oracle.com> <1379414362.2702.39.camel@cirrus> Message-ID: <20130917141709.4fd55e2cc324bea1eaf7fd99@danny.cz> On Tue, 17 Sep 2013 12:39:22 +0200 Thomas Schatzl wrote: > Hi Bengt, > > On Tue, 2013-09-17 at 11:48 +0200, Bengt Rutisson wrote: > > Hello Dan and Thomas, > > > > The change looks good to me to. Thanks for finding and fixing this! > > > > Thanks for the quick review. > > @Dan: The patch is now in the push queue and will go through the > hotspot-gc mercurial tree. thank you guys, any action still needed from me? There are other places in the hotspot code where int and size_t types are mixed (eg. in MAX2()/MIN2()) causing compile failures, so I'll submit another patch for these issues. Dan From stefan.karlsson at oracle.com Tue Sep 17 05:40:52 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 17 Sep 2013 14:40:52 +0200 Subject: RFR: 8024718: Metaspace performance counters and memory pools should report the same data In-Reply-To: <20130912214601.GC4100@ehelin-thinkpad> References: <20130912214601.GC4100@ehelin-thinkpad> Message-ID: <52384DD4.8040405@oracle.com> On 09/12/2013 11:46 PM, Erik Helin wrote: > Hi all, > > this patch fixes some issues with memory pools and the performance > counter reporting slightly different numbers for metaspace. I've also > updated two jtreg tests as well as added a new one to test the change. > > InputArguments.java in the testlibrary is updated as well. > InputArguments.contains now takes a prefix as a parameter instead of the > exact name of a flag. This makes it possible to check if a flag expecting > a value has been set. For example, -XX:MaxMetaspaceSize=100m can be > checked by running InputArguments.contains("-XX:MaxMetaspaceSize"). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8024718/webrev.00/ The vm code looks good. I just briefly looked at the test code, but you already have Reviewers for that. thanks, StefanK > > Testing: > - JPRT > - hotspot/test/gc (including updated and new tests) > > Thanks, > Erik From david.holmes at oracle.com Tue Sep 17 05:48:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 22:48:46 +1000 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <20130917141709.4fd55e2cc324bea1eaf7fd99@danny.cz> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> <52382564.3060709@oracle.com> <1379414362.2702.39.camel@cirrus> <20130917141709.4fd55e2cc324bea1eaf7fd99@danny.cz> Message-ID: <52384FAE.5000301@oracle.com> Hi Dan, On 17/09/2013 10:17 PM, Dan Hor?k wrote: > On Tue, 17 Sep 2013 12:39:22 +0200 > Thomas Schatzl wrote: > >> Hi Bengt, >> >> On Tue, 2013-09-17 at 11:48 +0200, Bengt Rutisson wrote: >>> Hello Dan and Thomas, >>> >>> The change looks good to me to. Thanks for finding and fixing this! >>> >> >> Thanks for the quick review. >> >> @Dan: The patch is now in the push queue and will go through the >> hotspot-gc mercurial tree. > > thank you guys, any action still needed from me? > > There are other places in the hotspot code where int and size_t types > are mixed (eg. in MAX2()/MIN2()) causing compile failures, so I'll > submit another patch for these issues. Have you actually eradicated all compile-time errors due to this issue? I worry that things will just unwravel as you try to do this. David > > Dan > From dan at danny.cz Tue Sep 17 06:53:17 2013 From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=) Date: Tue, 17 Sep 2013 15:53:17 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <52384FAE.5000301@oracle.com> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> <52382564.3060709@oracle.com> <1379414362.2702.39.camel@cirrus> <20130917141709.4fd55e2cc324bea1eaf7fd99@danny.cz> <52384FAE.5000301@oracle.com> Message-ID: <20130917155317.0b0e617f9148afff2b4f7646@danny.cz> On Tue, 17 Sep 2013 22:48:46 +1000 David Holmes wrote: > Hi Dan, > > On 17/09/2013 10:17 PM, Dan Hor?k wrote: > > On Tue, 17 Sep 2013 12:39:22 +0200 > > Thomas Schatzl wrote: > > > >> Hi Bengt, > >> > >> On Tue, 2013-09-17 at 11:48 +0200, Bengt Rutisson wrote: > >>> Hello Dan and Thomas, > >>> > >>> The change looks good to me to. Thanks for finding and fixing > >>> this! > >>> > >> > >> Thanks for the quick review. > >> > >> @Dan: The patch is now in the push queue and will go through the > >> hotspot-gc mercurial tree. > > > > thank you guys, any action still needed from me? > > > > There are other places in the hotspot code where int and size_t > > types are mixed (eg. in MAX2()/MIN2()) causing compile failures, so > > I'll submit another patch for these issues. > > Have you actually eradicated all compile-time errors due to this > issue? I worry that things will just unwravel as you try to do this. Some time ago the patch at [1] fixed all those conflicts and we similar patch for openjdk7 in Fedora. But I guess it will need an update for the recent sources. [1] http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk-size_t.patch Dan From harold.seigel at oracle.com Tue Sep 17 07:46:08 2013 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 17 Sep 2013 10:46:08 -0400 Subject: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk In-Reply-To: <5237C172.5000209@oracle.com> References: <005901ceaf61$28692130$793b6390$@oracle.com> <52315D1C.80404@oracle.com> <52318F39.5050706@oracle.com> <52319264.7030505@oracle.com> <523193C6.6080309@oracle.com> <5231A506.4070403@oracle.com> <5231ACFC.2090006@oracle.com> <20130912132259.GB2258@ehelin-thinkpad> <5232F2CB.8050902@oracle.com> <000501ceb0b2$593b9f70$0bb2de50$@oracle.com> <523661BE.9030302@oracle.com> <523662A7.4010800@oracle.com> <007401ceb326$5c7c4420$1574cc60$@oracle.com> <5237C172.5000209@oracle.com> Message-ID: <52386B30.4060408@oracle.com> Hi Christian, The changes look good. Thanks, Harold On 9/16/2013 10:41 PM, David Holmes wrote: > Thumbs up from me! > > Thanks, > David > > On 17/09/2013 7:47 AM, Christian Tornqvist wrote: >> Updated webrev where I've removed >> >> runtime/NMT/MallocTestType.java >> runtime/NMT/ThreadedMallocTestType.java >> runtime/NMT/ThreadedVirtualAllocTestType.java >> runtime/NMT/VirtualAllocTestType.java >> runtime/NMT/BaselineWithParameter.java >> runtime/NMT/JcmdScale.java >> runtime/NMT/JcmdWithNMTDisabled.java >> runtime/NMT/ShutdownTwice.java >> runtime/NMT/SummaryAfterShutdown.java >> runtime/NMT/SummarySanityCheck.java >> runtime/RedefineObject/TestRedefineObject.java >> >> from the needs_jdk group in TEST.groups based on David's comment in >> the bug. >> >> Webrev can be found at: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.04/ >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Sunday, September 15, 2013 9:45 PM >> To: Christian Tornqvist >> Cc: 'hotspot-dev developers' >> Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be >> updated to divide test jdk and compile jdk >> >> On 16/09/2013 11:41 AM, David Holmes wrote: >>> On 14/09/2013 4:52 AM, Christian Tornqvist wrote: >>>> I've added getCompileJDKTool() and getTestJDKTool(), the common >>>> function getJDKTool() will still look in test.jdk first and >>>> compile.jdk as a fallback. >>>> >>>> Changed the TestVerifyDuringStartup.java that Igor changed as part of >>>> his change to use getJDKTool() since this is what >>>> ProcessTools.createJavaProcessBuilder() does. >>>> >>>> Verified my change locally by running test/runtime and test/gc jtreg >>>> tests to verify that they work correctly when test.jdk is set to a >>>> JRE. >>>> >>>> New webrev can be found at: >>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.03/ >>> >>> Looks good to me! >>> >>> Thanks, >>> Chris >> >> That should be: >> >> Thanks, Chris. >> >> David >> ----- >> >> David >> ----- >> >> :) >> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: hotspot-runtime-dev-bounces at openjdk.java.net >>>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of >>>> David Holmes >>>> Sent: Friday, September 13, 2013 7:11 AM >>>> To: Erik Helin >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8014905 - [TESTBUG] Some hotspot tests should be >>>> updated to divide test jdk and compile jdk >>>> >>>> Just to cc the list what I said in other email ... >>>> >>>> I think this is a good compromise. Having an API that allows the test >>>> to select which JDK to use is important; but maintaining >>>> compatability with existing test behaviour is also important. >>>> >>>> Thanks, >>>> David >>>> >>>> On 12/09/2013 11:22 PM, Erik Helin wrote: >>>>> On 2013-09-12, David Holmes wrote: >>>>>> On 12/09/2013 9:27 PM, Igor Ignatyev wrote: >>>>>>> On 09/12/2013 02:13 PM, David Holmes wrote: >>>>>>>> On 12/09/2013 8:07 PM, Igor Ignatyev wrote: >>>>>>>>> On 09/12/2013 01:54 PM, David Holmes wrote: >>>>>>>>>> On 12/09/2013 4:20 PM, Igor Ignatyev wrote: >>>>>>>>>>> Christian, >>>>>>>>>>> >>>>>>>>>>> I have made some changes in JDKToolFinder w/ patch for >>>>>>>>>>> JDK-8012447[*]: >>>>>>>>>>> - getJDKTool uses 'compile.jdk' >>>>>>>>>>> - getCurrentJDKTool uses 'test.jdk' >>>>>>>>>>> >>>>>>>>>>> So, I'm not sure that your change is necessary. >>>>>>>>>> >>>>>>>>>> I prefer Christian's approach as it is behaviour preserving. >>>>>>>>>> With your change any test that actually wants/needs to use the >>>>>>>>>> test JDK will have to be modified. >>>>>>>>> I agree, but w/ Christian's approach we could get situation that >>>>>>>>> we test binary from another JDK, e.g. >>>>>>>>> 'test/gc/TestVerifyDuringStartup.java' >>>>>>>>> which used 'java' from 'compile.jdk' instead of 'test.jdk'. >>>>>>>> >>>>>>>> I don't see how as the test JDK is checked first. The gap in >>>>>>>> Christian's approach is the more rare case of where the test JDKs >>>>>>>> tool must not be used for that part of the test. >>>>>>> Oh sorry, I misread the code. Anyway, I don't think that this code >>>>>>> is good, because if I want to get one of jdk tool, I expect that I >>>>>>> will get it from '-compilejdk' if this option's specified, and >>>>>>> from '-jdk', otherwise. But w/ Christian's patch I will get tool >>>>>>> from '-jdk' if tool exists there, that may confuse. >>>>>> >>>>>> Anyone using this function has to know what it returns regardless >>>>>> of whether that is from compile-jdk or test-jdk. With your change a >>>>>> bunch of tests that were using the test-jdk tools will now be using >>>>>> the compile-jdk tools, and while that might not cause a test >>>>>> failure it might negate the purpose of the test. So unless you've >>>>>> examined all the tests that use this API I can't agree that your >>>>>> change was appropriate. >>>>> >>>>> I, Igor and Christian discussed this on IM and the solution that we >>>>> came up with was that JDKToolFinder should have three methods: >>>>> getJDKTool, getCompilerJDKTool and getTestJDKTool. getJDKTool >>>>> should, as in Christian's change, first try to make use of >>>>> getTestJDKTool and then, if that fails, use getCompilerJDKTool. >>>>> >>>>> getCompilerJDKTool and getTestJDKTool should be like the ones Igor >>>>> has written, but the should use make use of a private function to >>>>> avoid code duplication. >>>>> >>>>> This way, writing an simple test will still be easy, using >>>>> getJDKTool should in most cases be what you want. However, if you >>>>> are writing a more tricky test, getTestJDKTool and >>>>> getCompilerJDKTool are still there for those cases. >>>>> >>>>> David, what do think about this suggestion? >>>>> >>>>>>>> So I think >>>>>>>>> that any test that actually wants/needs to use the test JDK must >>>>>>>>> do it explicitly. >>>>>>>>>> >>>>>>>>>>> [*] >>>>>>>>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ceda33 >>>>>>>>>>> ff >>>>>>>>>>> 54a3 >>>>>>>>>> >>>>>>>>>> Was this reviewed on hotspot-dev/hotspot-runtime-dev or only >>>>>>>>>> hotspot-compiler-dev? >>>>>>>>> >>>>>>>>> It was reviewed only on hotspot-compiler-dev. >>>>>>>> >>>>>>>> These kinds of changes really have to be reviewed more broadly as >>>>>>>> they affect everyone. We wouldn't even have known about your >>>>>>>> change if Christian hadn't done this one. Plus the testlibrary >>>>>>>> really should have a nominal owner to coordinate things - and we >>>>>>>> need to make sure the hotspot and JDK versions are kept in sync. >>>>> >>>>> I guess that I and Christian usually try to monitor the changes to >>>>> the hotspot testlibrary, and I think Igor will start do it as well >>>>> :) This way, we at least have one from runtime, one from compiler >>>>> and one from gc. >>>>> >>>>> As for keeping the JDK and HotSpot versions in sync, well that is a >>>>> problem. One of the issues is that just because we in the hotspot >>>>> team reviewed and approved changes to HotSpot's testlibrary does not >>>>> automatically mean that the JDK team wants these patches. Therefore, >>>>> keeping the JDK and the HotSpot test libraries in sync will require >>>>> more work than just "moving patches". >>>>> >>>>> Unfortunately, I do not have any good solution for this at the >>>>> moment :( >>>>> >>>>>>> I fully agree w/ you and I'm really sorry about the situation. >>>>>>> But I don't see big difference between 'hotspot-runtime-dev' and >>>>>>> 'hotspot-compiler-dev', so *this* change "really have to be >>>>>>> reviewed more broadly as they affect everyone". >>>>>> >>>>>> I meant reviewing on hotspot-runtime-dev as well as >>>>>> hotspot-compiler-dev, not in place of. hotspot-dev could have been >>>>>> in place. >>>>> >>>>> I think hotspot-dev is better for changes to the hotspot testlibrary >>>>> since the changes affect all the hotspot devevelopers. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Igor Ignatyev >>>>>>>>>>> >>>>>>>>>>> On 09/12/2013 06:38 AM, Christian Tornqvist wrote: >>>>>>>>>>>> Hi everyone, >>>>>>>>>>>> >>>>>>>>>>>> Small change in JDKToolFinder so that it will now look in >>>>>>>>>>>> compile.jdk if the tool is not found in test.jdk. I?ve tested >>>>>>>>>>>> it locally by running tests with test.jdk set to a JRE and >>>>>>>>>>>> compile.jdk set to JDK to see that they work correctly. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.02 >>>>>>>>>>>> / >>>>>>>>>>>> >>>>>>>>>>>> Bug is unfortunately not visible externally at this time L >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Christian >>>>>>>>>>>> >>>> >> From mike.duigou at oracle.com Tue Sep 17 09:34:06 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 17 Sep 2013 09:34:06 -0700 Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps" In-Reply-To: <523802DD.3020709@oracle.com> References: <5237C05F.9050506@oracle.com> <523802DD.3020709@oracle.com> Message-ID: <4ABE2E27-FDFA-4309-9CD5-940D41F7AD28@oracle.com> On Sep 17 2013, at 00:21 , David Holmes wrote: > Hi Mike, > > Looks like there is one test that knows it has to exercise the alt-rt.jar version: > > ./java/util/TreeMap/Clone.java > > * @run main/othervm Clone > * @run main/othervm -XX:+AggressiveOpts Clone > > but it's harmless to leave the second invocation. I will remove it. Since the +AggressiveOpts option remains it is still valid. A better general solution (that I hope someone is running) is to run the entire jtreg suite with +AggressiveOpts as an extra JDK option. > I didn't see anything in JDK or hotspot regression tests that would be impacted. > > Once you are ready I will sponsor the hotspot patch for you through hotspot-rt. Thank you. Mike > > Thanks, > David > > On 17/09/2013 12:37 PM, David Holmes wrote: >> Reviewed both hotspot and jdk changes. >> >> Thumbs up and good riddance! :) >> >> How do you propose to handle the coordination of the push? >> >> Thanks, >> David >> >> On 17/09/2013 10:16 AM, Mike Duigou wrote: >>> Hello all; >>> >>> This is a cross-repo patch which disables building and enabling of the >>> alt-rt.jar file. The alt-rt.jar file has been used with the >>> -XX:+AggressiveOpts option (which will be remaining for other >>> optimizations). This jar file formerly contained (closed-source) >>> versions of several JDK classes which were optimized for very specific >>> workloads. The implementations weren't generally applicable and in >>> many cases induced performance drops. In particular since we will not >>> be providing optimized implementations of the Java 8 streams API for >>> the alternate versions of these classes the performance relative to >>> the standard implementations would be poor. >>> >>> Over time we've (largely Alan Bateman) been trying to eliminate this >>> difficult to support feature. With this changeset the alt-rt.jar >>> feature is retired. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ >>> >>> Ideally I would like a reviewer for both the HotSpot and JDK repos >>> (could be the same person). >>> >>> Mike >>> From John.Coomes at oracle.com Wed Sep 18 01:58:39 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 18 Sep 2013 01:58:39 -0700 Subject: new convention for hsx project repository names In-Reply-To: References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> <21025.7541.995077.658147@oracle.com> Message-ID: <21049.27455.758716.665454@oracle.com> Volker Simonis (volker.simonis at gmail.com) wrote: Hi Volker, It's taken a while for me to get back to this; see my responses inline below. > Hi John, > > HotSpot versioning has always been a kind of mystery. I'll try to explain my > understanding of if before I'll come to my question: > ... > The easy part is the "hsx/hotspot-main" repository. It contains the linear, > incremental development code line of the HotSpot. For convenience, larger > development frames are consecutively numbered with HotSpot version numbers > (i.e. hs23, hs24, etc.). Once a major development period is over (and before > the next one begins) the HotSpot may be branched into a stabilization > repository which until now is named according to the corresponding HotSpot > version number (i.e. hs23 -> hsx23). > > As the name "stabilization repositories" implies, they are used to stabilize a > HotSpot version for a release. Therefore changes from the main development code > line are selectively integrated into the hsxXY repositories (indicated by the > '+' sign in my drawing) as needed. Actually, the general rule of thumb is that > all the changes have to go trough the development code line (i.e. "hsx/ > hotspot-main") before they can be integrated into a "hsxXY" repository although > it already happened in the past that this rule has been violated. At some point > in time, hsxXY is considered stable and will be shipped inside a Java release > - say jdk7uMN. Yes, the above is correct. FWIW, the fixes that don't go through hsx/hotspot-main first are either not applicable (because the hotspot-main code has diverged), or critical items which would miss a deadline (or the release) if we had to wait for it to go to hotspot-main. We really dislike the latter. > But things get more complicated: at a certain point in time, there may be a > need to stabilize multiple hsxXY versions for different releases in parallel > (e.g. the next feature and the next security release or the next security > release and an exceptional security release). In such a case, new hsx > repositories are created with an additional, minor version number (e.g. > hsx23.1, hsx23.2). > > At this point things already get nebulous, because the relation of two hsx > versions hsx.XY.A and hsxXY.B is not always clear to me - i.e. it is not always > easy to see from which common ancestor change set they are branched. Yes, it can be hard to find the common ancestor. But the invariant is that hsx.XY.B was originally cloned from hsx.XY.A. There can be occasional merges from hsx.XY.A into hsx.XY.B, and a final merge when hsx.XY.A ships (or soon after). > Another problem is that within the OpenJDK we usually don't see all the > different hsx.XY.A repositories (some like the ones for security fixes are > Oracle-internal). Instead, they are all merged into the common hsx.XY > repository after they have been released. Right; these are primarily the security releases, which we cannot push into the open until the release has shipped. > So far that's how I understand the current situation (comments and corrections > always welcome:). You've reverse-engineered the process quite well. > Now my questions: > > 1. Will you still maintain the major and minor HotSpot versions numbers in make > /hotspot_version after branching the HotSpot sources to hsx/jdkXu and hsx/ > jdkXuYZ To keep the user-visible changes in jdk7 updates to a minimum, we will continue to use hsx major & minor version numbers there. However, we want to stop using them at some point, possibly as soon as jdk 8 (but that will be a stretch). > 2. What happens if hs26 will go into jdk8uXY. From my understanding of your > proposal we will end up with hs26 being in hsx/jdk9 AND hsx/jdk8u AND hsx/ > jdk8uXY AND any other hsx/jdk8uNM with NM > XY. Morover hsx/jdk8u will switch > from hsx25 to hsx26. If we did that, once we get to the point of needing a hsx/jdk8uXY stabilization tree, we would change hsx versions, since the sources will diverge. For example, jdk8uXY would stay hs26, and hsx/hotspot-main would become hs27. There are several possible variants depending upon how long we wanted to continue delivering hsx/hotspot-main into hsx/jdk8u. But a lot of this should be unnecessary, see below. > 3. What happens with the repositories which are not publicly visible? Will they > all be merged into hsx/jdk8u? We then may get the strange situation that we > merged hs26 into hsx/jdk8u because it will be backported into jdk8. Later on, > but before a jdk8 with hs26 will be released, we merge hs25.N (from a security > release) into hsx/jdk8u. This seems much more confusing than having distinct > hsx/hs25.N and hsx/hs26.M repositories. We've been doing the above in hs24/jdk7u for the last year, or more. For example, security release 7u25 (hs23.25) was merged into hs24 in hs24-b55; 7u21 (hs23.21) was also merged. Yes, the merges are a bit ugly, but are the lowest cost method of ensuring that all security fixes make it into later releases. That part of the process doesn't change, except for the naming, and it should be easier to follow. After it ships, jdk8u/jdk8u (a security release) would be merged into jdk8u/jdk8u, and eventually make its way into hsx/jdk8u. Fortunately, only the update releases have these merges; we won't see them in the hsx/hotspot-main repo. > 4. Why not just stay with the current scheme and just provide a list with the > hs to jdkXu mapping at a prominent place? We've maintained such a list internally, and it was still confusing to people who are responsible for tracking what's in releases, as well as to new developers and to those who work only occasionally with hotspot. It's just an extra step that can be eliminated. > In my opinion, your scheme will probably always cause trouble because there is > no one-to-one relation between the HotSpot and JDK version. It would be hard to > guarantee this because there might be always good reasons to downport a newer > HotSpot version into an already released JDK. We've (usually) had a 1-1 relation once we reach the point of needing a stabilization forest. And in practice, hotspot has been 1-1 for more than a year--hs25 has been delivered only to jdk8, and hs24 only to jdk7u40 during that time. As Staffan mentioned, that's a trend we expect to continue. There is less pressure to deliver every bug fix and every feature into old JDK releases. We may still backport many or even most fixes, but fewer features. There's also the cost of keeping hotspot compatible with multiple JDK releases, which requires that we support the associated old O/S versions and old tool chains. There are some crusty workarounds in the code that would be nice to remove. Larger features like jsr292 and native metadata (aka perm gen removal) would be painful to keep compatible, and involve more risk than is wanted for update releases, so it made the most sense to diverge for them. We want to make larger features like those easier to do in hotspot. -John > On Sat, Aug 31, 2013 at 12:32 AM, John Coomes wrote: > > David Holmes (david.holmes at oracle.com) wrote: > > Hi John, > > > > Can you clarify how the repository name change will affect the actual > > hotspot version info that is maintained in the repo, and reported via > > -version and -Xinternalversion. > > Hi David, > > The new convention only affects the repository names; the version > reported by the JVM will remain the same for now. > > Changing the version string is an obvious future step, but since it's > visible to users (not just developers), we have to be a bit more > careful. Look for more email on that in the coming weeks. > > -John > > > On 30/08/2013 2:09 PM, John Coomes wrote: > > > The hsx Project has maintained a version number for HotSpot that is > > > distinct from the JDK version--for example HotSpot version hs24 is > > > being delivered into jdk7u40, and hs25 into jdk8. (For interested > > > readers, some background info about separate versions is included at > > > the end of this message.) > > > > > > The separate version has also been reflected in repository paths, e.g.: > > > > > > http://hg.openjdk.java.net/hsx/hsx24 > > > http://hg.openjdk.java.net/hsx/hsx23 > > > http://hg.openjdk.java.net/hsx/hsx23.2 > > > http://hg.openjdk.java.net/hsx/hsx23.4 > > > ... > > > > > > One often-mentioned problem with this naming scheme is that the > > > correspondence between an hsx repository and the JDK release into which > > > it will be delivered is not obvious. So we are planning on changing > the > > > repository naming convention going forward. > > > > > > More precisely, the new repository for HotSpot (and HotSpot-related) > > > changes targeting jdk7u60 and later 7 updates would be: > > > > > > http://hg.openjdk.java.net/hsx/jdk7u > > > > > > (The old convention would have used the name http://.../hsx/hsx24.) > > > This new repo will correspond to the jdk7u on-going development repo, > > > i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. > > > > > > Extending this a little into the future, once jdk7u60 reaches a point > > > where a separate stabilization repo is needed, we will create > > > http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u > > > repo would change to target the following jdk7u update release (if > > > there is one). > > > > > > Similar conventions would apply to repositories for jdk8 updates once > > > we have a need for them. > > > > > > Existing hsx repos should continue to be used; in particular, we will > > > continue to use the on-going development repos for the forseeable > > > future: > > > > > > http://hg.openjdk.java.net/hsx/hotspot-main > > > http://hg.openjdk.java.net/hsx/hotspot-comp > > > http://hg.openjdk.java.net/hsx/hotspot-emb > > > http://hg.openjdk.java.net/hsx/hotspot-gc > > > http://hg.openjdk.java.net/hsx/hotspot-rt > > > > > > These are currently targeting jdk8, and will switch to jdk9 in the near > > > future. At that point a new jdk8 stabilization repo would be created: > > > > > > http://hg.openjdk.java.net/hsx/jdk8 > > > > > > to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is > > > currently used only by the hotspot gatekeeper, Alejandro Murillo). > > > > > > Despite the length of this message, I think the naming change is > > > straightforward and will (slightly) simplify HotSpot development. > > > Since there are already HotSpot changes pending for jdk7u60, I want to > > > create the new repo within the next few days. If you have questions > > > or feedback, please follow-up on the list. > > > > > > Background on the separate HotSpot version number: > > > > > > Because the same HotSpot source has been delivered simultaneously into > > > multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 > and > > > into jdk7u4, builds of hs22 were delivered into early jdk8 builds and > > > into jdk7u2, and so on), a separate HotSpot version facilitated > tracking > > > the sources as they propagated to different releases. But at the same > > > time, it also imposed the overhead of having to map from a HotSpot > > > version to a JDK version and back again. This is not always simple, > > > particularly for those that do not work with HotSpot on a day-to-day > > > basis. > > > > > > More recent hsx versions (hs24 and hs25), have really targeted only a > > > single JDK release (although a few builds of hs24 did go into both jdk8 > > > and into jdk7u). We expect this trend to continue, and thus the > > > overhead of mapping from a HotSpot version to a JDK version is > > > unnecessary. > > > > > > -John From zhengyu.gu at oracle.com Wed Sep 18 12:52:35 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 18 Sep 2013 19:52:35 +0000 Subject: hg: hsx/hotspot-main/hotspot: 22 new changesets Message-ID: <20130918195325.7585862919@hg.openjdk.java.net> Changeset: baa7927dfbd2 Author: zgu Date: 2013-09-04 08:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/baa7927dfbd2 8022798: "assert(seq > 0) failed: counter overflow" in Kitchensink Summary: Removed incorrect assertion, sequence number can overflow Reviewed-by: dholmes, kamg ! src/share/vm/services/memPtr.cpp Changeset: 38f750491293 Author: iklam Date: 2013-09-06 08:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/38f750491293 8022335: Native stack walk while generating hs_err does not work on Windows x64 Summary: Use WinDbg API StackWalk64() Reviewed-by: zgu, dholmes ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 592520c14121 Author: kevinw Date: 2013-09-09 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/592520c14121 8023478: Test fails with HS crash in GCNotifier. Reviewed-by: sla ! src/share/vm/services/gcNotifier.cpp Changeset: b6767a18b379 Author: hseigel Date: 2013-09-09 14:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b6767a18b379 8023167: JVM allows duplicate Runtime[In]VisibleTypeAnnotations attributes in ClassFile/field_info/method_info structures Summary: Add checks for duplicates and issue errors when detected. Reviewed-by: coleenp, zgu ! src/share/vm/classfile/classFileParser.cpp Changeset: 0f648fbe4404 Author: dsamersoff Date: 2013-09-11 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f648fbe4404 8024056: runtime/InitialThreadOverflow/testme.sh fails Summary: on some macines gcc not able to link cxx program Reviewed-by: dholmes ! test/runtime/InitialThreadOverflow/testme.sh Changeset: 1c6b721a3fbf Author: dsamersoff Date: 2013-09-12 15:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1c6b721a3fbf 8022617: Openjdk hotspot build is broken on BSD platforms using gcc Summary: Enforce of preprocessing of all assembly sources by assembler-with-cpp Reviewed-by: dholmes, erikj ! make/bsd/makefiles/gcc.make Changeset: 225cedaf9a4b Author: zgu Date: 2013-09-13 10:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/225cedaf9a4b Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 623d923529df Author: mgronlun Date: 2013-09-13 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/623d923529df 8021353: Event based tracing is missing thread exit Reviewed-by: allwin, acorn, dcubed, dholmes, egahlin ! src/share/vm/runtime/thread.cpp ! src/share/vm/trace/traceMacros.hpp Changeset: b89a1a870965 Author: mgronlun Date: 2013-09-13 19:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b89a1a870965 Merge ! src/share/vm/runtime/thread.cpp Changeset: ff8a09595db3 Author: sspitsyn Date: 2013-09-13 12:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff8a09595db3 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed Summary: Handle pending exceptions instead of firing a guarantee() Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: ce5ee9de50ce Author: sspitsyn Date: 2013-09-13 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce5ee9de50ce 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 0d3ff4d36a31 Author: sspitsyn Date: 2013-09-13 12:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0d3ff4d36a31 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b135b600a66c Author: sspitsyn Date: 2013-09-13 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b135b600a66c Merge Changeset: 2e6938dd68f2 Author: dholmes Date: 2013-09-16 07:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2e6938dd68f2 6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock Summary: Associate CLOCK_MONOTONIC with the pthread_cond_t objects used for relative timed waits Reviewed-by: dcubed, shade ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 4472884d8b37 Author: dcubed Date: 2013-09-16 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4472884d8b37 6986195: correctly identify Ubuntu as the operating system in crash report instead of "Debian" Summary: Cleanup and document how various Linux release info files are used by print_distro_info(). Reviewed-by: dcubed, dsamersoff, coleenp, iklam, omajid Contributed-by: gerald.thornbrugh at oracle.com ! src/os/linux/vm/os_linux.cpp Changeset: 42863137168c Author: acorn Date: 2013-09-16 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/42863137168c 8024647: Default method resolution with private superclass method Reviewed-by: kamg, minqi ! src/share/vm/classfile/defaultMethods.cpp Changeset: 921967020b3b Author: acorn Date: 2013-09-16 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/921967020b3b Merge Changeset: 621eda7235d2 Author: minqi Date: 2013-09-16 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/621eda7235d2 7164841: Improvements to the GC log file rotation Summary: made changes to easily identify current log file in rotation. Parameterize the input with %t for time replacement in file name. Reviewed-by: ccheung, tschatzl, tamao, zgu Contributed-by: yumin.qi at oracle.com ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 535973ddf22c Author: minqi Date: 2013-09-16 18:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/535973ddf22c Merge Changeset: 88d6b9a1c27c Author: mseledtsov Date: 2013-09-17 20:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/88d6b9a1c27c 8016029: test runtime/6878713/Test6878713.sh failed Summary: Rewrote test in Java; updated the test condition to reflect latest changes in the source Reviewed-by: dholmes, ctornqvi - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar + test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java + test/runtime/ClassFile/testcase.jar Changeset: 6f45933aef35 Author: mseledtsov Date: 2013-09-17 20:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6f45933aef35 7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test Summary: Re-wrote in Java, this also eliminated temporary result file; set upper limit on malloc'd memory Reviewed-by: dcubed, dholmes, ccheung - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar + test/runtime/ClassFile/JsrRewriting.java + test/runtime/ClassFile/JsrRewritingTestCase.jar Changeset: 41e6ae9f6dd7 Author: zgu Date: 2013-09-18 12:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41e6ae9f6dd7 Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar From christian.tornqvist at oracle.com Wed Sep 18 15:59:05 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 18 Sep 2013 18:59:05 -0400 Subject: RFR(XS): 8024677 - [TESTBUG] Move tests for classes in /testlibrary Message-ID: <000201ceb4c2$ad243750$076ca5f0$@oracle.com> Hi, This change simply moves the jtreg tests for the classes in testlibrary out of testlibrary. I've updated TEST.groups to add the new directory but kept testlibrary in there since the CTW tests are still there. Change has been verified by running the tests in the new location locally on my machine. Bug: https://bugs.openjdk.java.net/browse/JDK-8024677 Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8024677/webrev.00/ Thanks, Christian From david.holmes at oracle.com Wed Sep 18 20:42:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Sep 2013 13:42:48 +1000 Subject: RFR(XS): 8024677 - [TESTBUG] Move tests for classes in /testlibrary In-Reply-To: <000201ceb4c2$ad243750$076ca5f0$@oracle.com> References: <000201ceb4c2$ad243750$076ca5f0$@oracle.com> Message-ID: <523A72B8.90207@oracle.com> Looks good to me. Thanks, David On 19/09/2013 8:59 AM, Christian Tornqvist wrote: > Hi, > > > > This change simply moves the jtreg tests for the classes in testlibrary out > of testlibrary. I've updated TEST.groups to add the new directory but kept > testlibrary in there since the CTW tests are still there. > > > > Change has been verified by running the tests in the new location locally on > my machine. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8024677 > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8024677/webrev.00/ > > > > Thanks, > > Christian > From david.holmes at oracle.com Wed Sep 18 21:14:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Sep 2013 14:14:18 +1000 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <20130917155317.0b0e617f9148afff2b4f7646@danny.cz> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> <52382564.3060709@oracle.com> <1379414362.2702.39.camel@cirrus> <20130917141709.4fd55e2cc324bea1eaf7fd99@danny.cz> <52384FAE.5000301@oracle.com> <20130917155317.0b0e617f9148afff2b4f7646@danny.cz> Message-ID: <523A7A1A.1060208@oracle.com> On 17/09/2013 11:53 PM, Dan Hor?k wrote: > On Tue, 17 Sep 2013 22:48:46 +1000 > David Holmes wrote: > >> Hi Dan, >> >> On 17/09/2013 10:17 PM, Dan Hor?k wrote: >>> On Tue, 17 Sep 2013 12:39:22 +0200 >>> Thomas Schatzl wrote: >>> >>>> Hi Bengt, >>>> >>>> On Tue, 2013-09-17 at 11:48 +0200, Bengt Rutisson wrote: >>>>> Hello Dan and Thomas, >>>>> >>>>> The change looks good to me to. Thanks for finding and fixing >>>>> this! >>>>> >>>> >>>> Thanks for the quick review. >>>> >>>> @Dan: The patch is now in the push queue and will go through the >>>> hotspot-gc mercurial tree. >>> >>> thank you guys, any action still needed from me? >>> >>> There are other places in the hotspot code where int and size_t >>> types are mixed (eg. in MAX2()/MIN2()) causing compile failures, so >>> I'll submit another patch for these issues. >> >> Have you actually eradicated all compile-time errors due to this >> issue? I worry that things will just unwravel as you try to do this. > > Some time ago the patch at [1] fixed all those conflicts and we > similar patch for openjdk7 in Fedora. But I guess it will need an > update for the recent sources. > > [1] > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk-size_t.patch Shouldn't the integer promotion rules handle this without needing casts? I'm not clearly seeing the problem here. And apologies as I'm just about to disappear on vacation with no email access. David > > Dan > From staffan.larsen at oracle.com Thu Sep 19 00:29:23 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 19 Sep 2013 09:29:23 +0200 Subject: RFR(XS): 8024677 - [TESTBUG] Move tests for classes in /testlibrary In-Reply-To: <000201ceb4c2$ad243750$076ca5f0$@oracle.com> References: <000201ceb4c2$ad243750$076ca5f0$@oracle.com> Message-ID: Looks good! /Staffan On 19 sep 2013, at 00:59, Christian Tornqvist wrote: > Hi, > > > > This change simply moves the jtreg tests for the classes in testlibrary out > of testlibrary. I've updated TEST.groups to add the new directory but kept > testlibrary in there since the CTW tests are still there. > > > > Change has been verified by running the tests in the new location locally on > my machine. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8024677 > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8024677/webrev.00/ > > > > Thanks, > > Christian > From bertrand.delsart at oracle.com Thu Sep 19 00:31:07 2013 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Thu, 19 Sep 2013 07:31:07 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20130919073119.6A10D62937@hg.openjdk.java.net> Changeset: 8e94527f601e Author: bpittore Date: 2013-09-11 20:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8e94527f601e 8024007: Misc. cleanup of static agent code Summary: Minor cleanup of static agent code from 8014135 Reviewed-by: dcubed, sspitsyn ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp Changeset: de88570fabfc Author: dholmes Date: 2013-09-11 00:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de88570fabfc 8024256: Minimal VM build is broken with PCH disabled Reviewed-by: coleenp, twisti ! make/excludeSrc.make ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 4c9d415db1c5 Author: dholmes Date: 2013-09-11 23:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c9d415db1c5 Merge Changeset: b1491b0303ee Author: bdelsart Date: 2013-09-13 07:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b1491b0303ee Merge Changeset: 10efeefa6485 Author: dholmes Date: 2013-09-13 21:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/10efeefa6485 8024505: [TESTBUG] update test groups for additional tests that can't run on the minimal VM Reviewed-by: coleenp, hseigel ! test/TEST.groups Changeset: cc5b40a76049 Author: bdelsart Date: 2013-09-18 21:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc5b40a76049 Merge ! src/share/vm/runtime/thread.cpp From thomas.schatzl at oracle.com Thu Sep 19 03:19:31 2013 From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com) Date: Thu, 19 Sep 2013 10:19:31 +0000 Subject: hg: hsx/hotspot-main/hotspot: 28 new changesets Message-ID: <20130919102045.3EF226293E@hg.openjdk.java.net> Changeset: 7944aba7ba41 Author: ehelin Date: 2013-08-12 17:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7944aba7ba41 8015107: NPG: Use consistent naming for metaspace concepts Reviewed-by: coleenp, mgerdin, hseigel ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp + test/gc/arguments/TestCompressedClassFlags.java - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java + test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java ! test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 440edcf30231 Author: mgerdin Date: 2013-09-11 08:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/440edcf30231 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 Summary: The code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden because compressed oops and compressed klasses has used the same base address in the past. Reviewed-by: sla, jmasa Contributed-by: stefan.johansson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java Changeset: f7bc2ab5f659 Author: tschatzl Date: 2013-09-11 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f7bc2ab5f659 8016825: Large pages for the heap broken on Windows for compressed oops Summary: Correctly pass the requested base address for the heap to the OS function to reserve memory. Reviewed-by: brutisso, stefank ! src/os/windows/vm/os_windows.cpp Changeset: ff218fdb30ba Author: tschatzl Date: 2013-09-11 10:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff218fdb30ba 8021823: G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs Summary: Correctly calculate the initialization value for the shift between object start and bitmap bit in the G1 mark bitmaps. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp + test/gc/TestObjectAlignment.java Changeset: 040895ec3920 Author: tschatzl Date: 2013-09-11 12:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/040895ec3920 Merge Changeset: 24e87613ee58 Author: mgerdin Date: 2013-09-11 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24e87613ee58 8009561: NPG: Metaspace fragmentation when retiring a Metachunk Summary: Use best-fit block-splitting freelist allocation from the block freelist. Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.cpp Changeset: 6608fa23708f Author: mgerdin Date: 2013-09-11 06:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6608fa23708f Merge Changeset: 40136aa2cdb1 Author: tschatzl Date: 2013-09-11 16:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/40136aa2cdb1 8010722: assert: failed: heap size is too big for compressed oops Summary: Use conservative assumptions of required alignment for the various garbage collector components into account when determining the maximum heap size that supports compressed oops. Using this conservative value avoids several circular dependencies in the calculation. Reviewed-by: stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp + test/gc/arguments/TestUseCompressedOopsErgo.java + test/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b82260e84582 Author: tschatzl Date: 2013-09-11 18:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b82260e84582 Merge Changeset: d6c266999345 Author: ehelin Date: 2013-09-12 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d6c266999345 8023476: Metaspace capacity > reserved Reviewed-by: stefank, hseigel, mgerdin ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp Changeset: c4c768305a8f Author: stefank Date: 2013-09-12 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c4c768305a8f 8024638: Count and expose the amount of committed memory in the metaspaces Reviewed-by: brutisso, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 335b388c4b28 Author: stefank Date: 2013-09-13 22:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/335b388c4b28 8024651: Remove the incorrect usage of Metablock::overhead() Reviewed-by: brutisso, mgerdin, coleenp, jmasa ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metaspace.cpp Changeset: 9e11762cee52 Author: stefank Date: 2013-09-13 22:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9e11762cee52 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize Reviewed-by: jwilhelm, brutisso, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/metaspace/TestMetaspaceSizeFlags.java ! test/testlibrary/OutputAnalyzerTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java Changeset: 8227700da288 Author: stefank Date: 2013-09-13 22:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8227700da288 8024751: Fix bugs in TraceMetadata Reviewed-by: jmasa, brutisso ! src/share/vm/memory/metaspace.cpp Changeset: 8c5e6482cbfc Author: stefank Date: 2013-09-13 22:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c5e6482cbfc 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty Reviewed-by: brutisso, mgerdin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 9cb63cd234a0 Author: shade Date: 2013-09-13 07:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9cb63cd234a0 8024671: G1 generates assert error messages in product builds Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 884ed7a10f09 Author: tschatzl Date: 2013-09-16 09:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/884ed7a10f09 Merge ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/globals.hpp Changeset: 23ae5a04724d Author: tschatzl Date: 2013-09-16 10:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/23ae5a04724d 8024396: VM crashing with assert(!UseLargePages || UseParallelOldGC || use_large_pages) failed: Wrong alignment to use large pages Summary: Loosen wrong assert for UseParallelOldGC to UseParallelGC Reviewed-by: stefank, brutisso ! src/share/vm/memory/universe.cpp + test/gc/arguments/TestAlignmentToUseLargePages.java Changeset: f9b58dbeab91 Author: tschatzl Date: 2013-09-16 13:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9b58dbeab91 Merge Changeset: 17deed6716af Author: tschatzl Date: 2013-09-17 12:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/17deed6716af 8024914: Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp Summary: Incorrect usage of idx_t where bm_word_t is appropriate. Reviewed-by: tschatzl, brutisso Contributed-by: Dan Horak ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 5767996b7b7b Author: jwilhelm Date: 2013-09-17 14:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5767996b7b7b 8024884: Test name changed, test list not updated Summary: Updated the test list with the new test name. Reviewed-by: brutisso, ehelin ! test/TEST.groups Changeset: fac394091d73 Author: jwilhelm Date: 2013-09-18 00:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fac394091d73 Merge Changeset: 73d0d0218068 Author: ehelin Date: 2013-09-17 20:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/73d0d0218068 8024718: Metaspace performance counters and memory pools should report the same data Reviewed-by: stefank, dholmes, coleenp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryUsage.hpp ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java + test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/testlibrary/com/oracle/java/testlibrary/InputArguments.java Changeset: 2f426063daea Author: tschatzl Date: 2013-09-18 10:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f426063daea 8024662: gc/arguments/TestUseCompressedOopsErgo.java does not compile. Summary: Fix compilation error and use of an outdated VM option in the test Reviewed-by: stefank, jwilhelm ! test/gc/arguments/TestUseCompressedOopsErgoTools.java Changeset: 9044964f9163 Author: tschatzl Date: 2013-09-18 13:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9044964f9163 8024669: Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9 Summary: After changes in 8010722 the ergonomics for calculating the size of the heap that supports zero based compressed oops changed. This lead to the VM actually using zero based compressed oops. Due to low default HeapBaseMinAddress, the OS mapping in the application image at the same address, and limitations of the malloc implementation on Solaris this resulted in very little C heap available for the VM. So the VM immediately gives a native OOME when the machine has lots of physical memory (>=32G). The solution is to increase the HeapBaseMinAddress so that the VM has enough C heap. Reviewed-by: kvn, brutisso ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp Changeset: 719e886d4f72 Author: tschatzl Date: 2013-09-18 15:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/719e886d4f72 Merge Changeset: 06ae47d9d088 Author: tschatzl Date: 2013-09-19 09:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/06ae47d9d088 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 179cd89fb279 Author: tschatzl Date: 2013-09-19 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/179cd89fb279 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! test/TEST.groups From stefan.karlsson at oracle.com Thu Sep 19 07:59:15 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Sep 2013 16:59:15 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Message-ID: <523B1143.8080602@oracle.com> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8025059 The following code in Metaspace::should_expand: if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { size_t real_allocated = Metaspace::space_list()->reserved_words() + MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); if (real_allocated >= MaxMetaspaceSize) { return false; } doesn't convert Metaspace::space_list()->reserved_words() to bytes, as it should. Note that when JDK-8024547 gets fixed, this check will be rewritten to limit the amount of committed memory in both the Class and NonClass metaspaces. See: https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Testing: I've run our internal testing that sets the MaxMetaspaceSize. thanks, StefanK From bengt.rutisson at oracle.com Thu Sep 19 08:10:02 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 19 Sep 2013 17:10:02 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B1143.8080602@oracle.com> References: <523B1143.8080602@oracle.com> Message-ID: <523B13CA.5050406@oracle.com> Hi Stefan, Given that we just want to get the byte/word conversion right I think this change is fine. The bug JDK-8024547 contains a long list of improvements so it is a bit difficult to tell, but the asymmetry with using reserved memory for NonClassType and allocated memory for ClassType will go away with some of the changes for JDK-8024547, right? 1345 size_t nonclass_allocated = MetaspaceAux::reserved_bytes(Metaspace::NonClassType); 1346 size_t class_allocated = MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); 1347 size_t real_allocated = nonclass_allocated + real_allocated; Thanks, Bengt On 9/19/13 4:59 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8025059 > > The following code in Metaspace::should_expand: > > if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { > size_t real_allocated = Metaspace::space_list()->reserved_words() + > MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); > if (real_allocated >= MaxMetaspaceSize) { > return false; > } > > doesn't convert Metaspace::space_list()->reserved_words() to bytes, as > it should. > > Note that when JDK-8024547 gets fixed, this check will be rewritten to > limit the amount of committed memory in both the Class and NonClass > metaspaces. See: > https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize > should limit the committed memory used by the metaspaces > > Testing: I've run our internal testing that sets the MaxMetaspaceSize. > > thanks, > StefanK From coleen.phillimore at oracle.com Thu Sep 19 08:22:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Sep 2013 11:22:15 -0400 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B13CA.5050406@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> Message-ID: <523B16A7.5090606@oracle.com> Yes, I'm confused why you're fixing this now and not with the change that really fixes it to be consistent. Does it enable more tests to run? Thanks, Coleen On 09/19/2013 11:10 AM, Bengt Rutisson wrote: > > Hi Stefan, > > Given that we just want to get the byte/word conversion right I think > this change is fine. The bug JDK-8024547 contains a long list of > improvements so it is a bit difficult to tell, but the asymmetry with > using reserved memory for NonClassType and allocated memory for > ClassType will go away with some of the changes for JDK-8024547, right? > > 1345 size_t nonclass_allocated = > MetaspaceAux::reserved_bytes(Metaspace::NonClassType); > 1346 size_t class_allocated = > MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); > 1347 size_t real_allocated = nonclass_allocated + real_allocated; > > Thanks, > Bengt > > > On 9/19/13 4:59 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025059 >> >> The following code in Metaspace::should_expand: >> >> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >> size_t real_allocated = Metaspace::space_list()->reserved_words() + >> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >> if (real_allocated >= MaxMetaspaceSize) { >> return false; >> } >> >> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >> as it should. >> >> Note that when JDK-8024547 gets fixed, this check will be rewritten >> to limit the amount of committed memory in both the Class and >> NonClass metaspaces. See: >> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >> should limit the committed memory used by the metaspaces >> >> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >> >> thanks, >> StefanK > From goetz.lindenmaier at sap.com Thu Sep 19 08:44:45 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Sep 2013 15:44:45 +0000 Subject: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Message-ID: <4295855A5C1DE049A61835A1887419CC0D0341D6@DEWDFEMB12A.global.corp.sap> Hi, We extended adlc by a feature that allows to specify fields of MachNodes. http://cr.openjdk.java.net/~goetz/webrevs/8024922-adlcFields/ This is implemented according to the ins_xxx() functionality that allows to specify functions returning constants. If you specify an ins_field_xxx(tp) in an instruct specification, a field _xxx with type tp is added to the node. You can see a usage of this feature in the ppc.ad file: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/ppc.ad E.g., on line 12928 you find the specification of _load_ic_hi_node: 12928 instruct CallDynamicJavaDirect__2(method meth) %{ 12924 match(CallDynamicJava); // To get all the data fields we need ... 12925 effect(USE meth); 12926 predicate(false); // ... but never match. 12927 12928 ins_field_load_ic_hi_node(exLoadConL_hiNode*); which is used on line 5098: 5098 { 5099 CallDynamicJavaDirect__2Node *m1 = (CallDynamicJavaDirect__2Node *)call; 5100 m1->_load_ic_hi_node = exLoadConLNodes_IC._large_hi; 5101 m1->_load_ic_node = exLoadConLNodes_IC._small; 5102 } As with other ins_ attributes, a general declaration of the attribute is needed, see line 6565: 6565 ins_attrib ins_field_load_ic_hi_node(0); In adlc, we just had to change the output of nodes. Parsing of the ad file is not affected. This change only affects adlc. There should be no effects on the Oracle platforms, except if a closed platform happens to specify an attribute with the name prefix ins_field_. Please review and test this change. Best regards, Goetz. From stefan.karlsson at oracle.com Thu Sep 19 10:01:04 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Sep 2013 19:01:04 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B13CA.5050406@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> Message-ID: <523B2DD0.1030402@oracle.com> On 9/19/13 5:10 PM, Bengt Rutisson wrote: > > Hi Stefan, > > Given that we just want to get the byte/word conversion right I think > this change is fine. The bug JDK-8024547 contains a long list of > improvements so it is a bit difficult to tell, but the asymmetry with > using reserved memory for NonClassType and allocated memory for > ClassType will go away with some of the changes for JDK-8024547, right? > > 1345 size_t nonclass_allocated = > MetaspaceAux::reserved_bytes(Metaspace::NonClassType); > 1346 size_t class_allocated = > MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); > 1347 size_t real_allocated = nonclass_allocated + real_allocated; Yes. The current code we're working on calls MetaspaceAux::committed_bytes() directly. StefanK > > Thanks, > Bengt > > > On 9/19/13 4:59 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025059 >> >> The following code in Metaspace::should_expand: >> >> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >> size_t real_allocated = Metaspace::space_list()->reserved_words() + >> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >> if (real_allocated >= MaxMetaspaceSize) { >> return false; >> } >> >> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >> as it should. >> >> Note that when JDK-8024547 gets fixed, this check will be rewritten >> to limit the amount of committed memory in both the Class and >> NonClass metaspaces. See: >> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >> should limit the committed memory used by the metaspaces >> >> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Thu Sep 19 10:09:02 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Sep 2013 19:09:02 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B16A7.5090606@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> <523B16A7.5090606@oracle.com> Message-ID: <523B2FAE.4020107@oracle.com> On 9/19/13 5:22 PM, Coleen Phillimore wrote: > > Yes, I'm confused why you're fixing this now and not with the change > that really fixes it to be consistent. Does it enable more tests to run? The main reason is that I'm not the only one working on JDK-8024547, and pushing some of my patches out to the hotspot-gc will make it easier for the others to help out with some of the listed issues. StefanK > Thanks, > Coleen > > On 09/19/2013 11:10 AM, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> Given that we just want to get the byte/word conversion right I think >> this change is fine. The bug JDK-8024547 contains a long list of >> improvements so it is a bit difficult to tell, but the asymmetry with >> using reserved memory for NonClassType and allocated memory for >> ClassType will go away with some of the changes for JDK-8024547, right? >> >> 1345 size_t nonclass_allocated = >> MetaspaceAux::reserved_bytes(Metaspace::NonClassType); >> 1346 size_t class_allocated = >> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >> 1347 size_t real_allocated = nonclass_allocated + >> real_allocated; >> >> Thanks, >> Bengt >> >> >> On 9/19/13 4:59 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>> >>> The following code in Metaspace::should_expand: >>> >>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> if (real_allocated >= MaxMetaspaceSize) { >>> return false; >>> } >>> >>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >>> as it should. >>> >>> Note that when JDK-8024547 gets fixed, this check will be rewritten >>> to limit the amount of committed memory in both the Class and >>> NonClass metaspaces. See: >>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces >>> >>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>> >>> thanks, >>> StefanK >> > From vladimir.kozlov at oracle.com Thu Sep 19 10:25:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Sep 2013 10:25:03 -0700 Subject: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D0341D6@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D0341D6@DEWDFEMB12A.global.corp.sap> Message-ID: <523B336F.90903@oracle.com> Could you explain why you need _load_ic_*_node fields CallDynamicJavaDirect mach node? I am trying to understand if there is an other, already existing, way to do that. I am fine with these changes but I need to know why. Thanks, Vladimir On 9/19/13 8:44 AM, Lindenmaier, Goetz wrote: > Hi, > > We extended adlc by a feature that allows to specify fields of > > MachNodes. > > http://cr.openjdk.java.net/~goetz/webrevs/8024922-adlcFields/ > > This is implemented according to the ins_xxx() functionality that > > allows to specify functions returning constants. If you specify > > an ins_field_xxx(tp) in an instruct specification, a field _xxx > > with type tp is added to the node. > > You can see a usage of this feature in the ppc.ad file: > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/ppc.ad > > E.g., on line 12928 you find the specification of _load_ic_hi_node: > > 12928 instruct CallDynamicJavaDirect__2(method meth) %{ > > 12924 match(CallDynamicJava); // To get all the data fields we > need ... > > 12925 effect(USE meth); > > 12926 predicate(false); // ... but never match. > > 12927 > > 12928 ins_field_load_ic_hi_node(exLoadConL_hiNode*); > > which is used on line 5098: > > 5098 { > > 5099 CallDynamicJavaDirect__2Node *m1 = > (CallDynamicJavaDirect__2Node *)call; > > 5100 m1->_load_ic_hi_node = exLoadConLNodes_IC._large_hi; > > 5101 m1->_load_ic_node = exLoadConLNodes_IC._small; > > 5102 } > > As with other ins_ attributes, a general declaration of the attribute is > needed, see > > line 6565: > > 6565 ins_attrib ins_field_load_ic_hi_node(0); > > In adlc, we just had to change the output of nodes. Parsing of the ad file > > is not affected. > > This change only affects adlc. There should be no effects on the Oracle > > platforms, except if a closed platform happens to specify an attribute > > with the name prefix ins_field_. > > Please review and test this change. > > Best regards, > > Goetz. > From john.coomes at oracle.com Thu Sep 19 10:32:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 17:32:06 +0000 Subject: hg: hsx/hotspot-main: 14 new changesets Message-ID: <20130919173207.8F04B6296E@hg.openjdk.java.net> Changeset: 6d7f27953da6 Author: mduigou Date: 2013-09-03 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6d7f27953da6 8024200: handle hg wrapper with space after #! Reviewed-by: tbell ! common/bin/hgforest.sh Changeset: 73355c4c1bc8 Author: lana Date: 2013-09-06 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/73355c4c1bc8 Merge Changeset: 67f64101616e Author: mduigou Date: 2013-09-13 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/67f64101616e 8024201: Update bugdatabase url Reviewed-by: wetmore ! make/scripts/webrev.ksh Changeset: 4bf059350c51 Author: lana Date: 2013-09-17 08:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4bf059350c51 Merge Changeset: 8dadd26c2a58 Author: ihse Date: 2013-09-12 10:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8dadd26c2a58 8024467: Update autoconf-config.guess to autoconf 2.69 Reviewed-by: erikj ! common/autoconf/build-aux/autoconf-config.guess Changeset: 64f52ef175a4 Author: ihse Date: 2013-09-12 10:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/64f52ef175a4 8010185: Build should support --with-override-nashorn Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 Changeset: b1e9396fb8af Author: vadim Date: 2013-09-12 12:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b1e9396fb8af 8008022: Upgrade Direct X SDK used to build JDK Reviewed-by: erikj, prr, ihse ! Makefile ! README-builds.html ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 69da99676239 Author: ihse Date: 2013-09-13 13:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/69da99676239 8024620: config.log does not end up in corresponding configuration Reviewed-by: erikj ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh Changeset: ac3f5137f84d Author: ihse Date: 2013-09-13 14:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ac3f5137f84d 8024665: Move open changes for JDK-8020411 to closed source Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: aab351790498 Author: katleman Date: 2013-09-17 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/aab351790498 Merge Changeset: 59d6af7422af Author: katleman Date: 2013-09-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/59d6af7422af Merge Changeset: 7697621037fd Author: ihse Date: 2013-09-18 12:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7697621037fd 8024815: Make --with-dxsdk and friends deprecated Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 9286a6e61291 Author: ihse Date: 2013-09-18 13:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9286a6e61291 8024849: Don't remove upper case letters from username when setting USER_RELEASE_SUFFIX Reviewed-by: erikj ! common/autoconf/basics_windows.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: d4762f463fe0 Author: cl Date: 2013-09-19 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d4762f463fe0 Added tag jdk8-b108 for changeset 9286a6e61291 ! .hgtags From john.coomes at oracle.com Thu Sep 19 10:32:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 17:32:28 +0000 Subject: hg: hsx/hotspot-main/corba: 4 new changesets Message-ID: <20130919173234.1413F6296F@hg.openjdk.java.net> Changeset: af8e5bc3a150 Author: coffeys Date: 2013-09-03 22:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/af8e5bc3a150 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java Changeset: 4853dc082c7d Author: lana Date: 2013-09-06 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/4853dc082c7d Merge Changeset: a4bb3b450016 Author: lana Date: 2013-09-17 08:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a4bb3b450016 Merge Changeset: c1eb93f57603 Author: cl Date: 2013-09-19 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/c1eb93f57603 Added tag jdk8-b108 for changeset a4bb3b450016 ! .hgtags From john.coomes at oracle.com Thu Sep 19 10:32:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 17:32:46 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b108 for changeset 8ade3eed63da Message-ID: <20130919173258.B953E62970@hg.openjdk.java.net> Changeset: 21b10835b88a Author: cl Date: 2013-09-19 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/21b10835b88a Added tag jdk8-b108 for changeset 8ade3eed63da ! .hgtags From john.coomes at oracle.com Thu Sep 19 10:33:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 17:33:10 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b108 for changeset d1ea68556fd7 Message-ID: <20130919173318.E71B562971@hg.openjdk.java.net> Changeset: f64b1e497722 Author: cl Date: 2013-09-19 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/f64b1e497722 Added tag jdk8-b108 for changeset d1ea68556fd7 ! .hgtags From coleen.phillimore at oracle.com Thu Sep 19 10:27:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Sep 2013 13:27:13 -0400 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B2FAE.4020107@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> <523B16A7.5090606@oracle.com> <523B2FAE.4020107@oracle.com> Message-ID: <523B33F1.3090303@oracle.com> Ok, then. Looks good. Coleen On 09/19/2013 01:09 PM, Stefan Karlsson wrote: > On 9/19/13 5:22 PM, Coleen Phillimore wrote: >> >> Yes, I'm confused why you're fixing this now and not with the change >> that really fixes it to be consistent. Does it enable more tests to >> run? > > The main reason is that I'm not the only one working on JDK-8024547, > and pushing some of my patches out to the hotspot-gc will make it > easier for the others to help out with some of the listed issues. > > StefanK > >> Thanks, >> Coleen >> >> On 09/19/2013 11:10 AM, Bengt Rutisson wrote: >>> >>> Hi Stefan, >>> >>> Given that we just want to get the byte/word conversion right I >>> think this change is fine. The bug JDK-8024547 contains a long list >>> of improvements so it is a bit difficult to tell, but the asymmetry >>> with using reserved memory for NonClassType and allocated memory for >>> ClassType will go away with some of the changes for JDK-8024547, right? >>> >>> 1345 size_t nonclass_allocated = >>> MetaspaceAux::reserved_bytes(Metaspace::NonClassType); >>> 1346 size_t class_allocated = >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> 1347 size_t real_allocated = nonclass_allocated + >>> real_allocated; >>> >>> Thanks, >>> Bengt >>> >>> >>> On 9/19/13 4:59 PM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>>> >>>> The following code in Metaspace::should_expand: >>>> >>>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>>> if (real_allocated >= MaxMetaspaceSize) { >>>> return false; >>>> } >>>> >>>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >>>> as it should. >>>> >>>> Note that when JDK-8024547 gets fixed, this check will be rewritten >>>> to limit the amount of committed memory in both the Class and >>>> NonClass metaspaces. See: >>>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>>> should limit the committed memory used by the metaspaces >>>> >>>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>>> >>>> thanks, >>>> StefanK >>> >> > From stefan.karlsson at oracle.com Thu Sep 19 10:40:13 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Sep 2013 19:40:13 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B33F1.3090303@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> <523B16A7.5090606@oracle.com> <523B2FAE.4020107@oracle.com> <523B33F1.3090303@oracle.com> Message-ID: <523B36FD.2080503@oracle.com> On 9/19/13 7:27 PM, Coleen Phillimore wrote: > > Ok, then. Looks good. Thanks, Coleen. StefanK > > Coleen > > On 09/19/2013 01:09 PM, Stefan Karlsson wrote: >> On 9/19/13 5:22 PM, Coleen Phillimore wrote: >>> >>> Yes, I'm confused why you're fixing this now and not with the change >>> that really fixes it to be consistent. Does it enable more tests to >>> run? >> >> The main reason is that I'm not the only one working on JDK-8024547, >> and pushing some of my patches out to the hotspot-gc will make it >> easier for the others to help out with some of the listed issues. >> >> StefanK >> >>> Thanks, >>> Coleen >>> >>> On 09/19/2013 11:10 AM, Bengt Rutisson wrote: >>>> >>>> Hi Stefan, >>>> >>>> Given that we just want to get the byte/word conversion right I >>>> think this change is fine. The bug JDK-8024547 contains a long list >>>> of improvements so it is a bit difficult to tell, but the asymmetry >>>> with using reserved memory for NonClassType and allocated memory >>>> for ClassType will go away with some of the changes for >>>> JDK-8024547, right? >>>> >>>> 1345 size_t nonclass_allocated = >>>> MetaspaceAux::reserved_bytes(Metaspace::NonClassType); >>>> 1346 size_t class_allocated = >>>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>>> 1347 size_t real_allocated = nonclass_allocated + >>>> real_allocated; >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 9/19/13 4:59 PM, Stefan Karlsson wrote: >>>>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>>>> >>>>> The following code in Metaspace::should_expand: >>>>> >>>>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>>>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>>>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>>>> if (real_allocated >= MaxMetaspaceSize) { >>>>> return false; >>>>> } >>>>> >>>>> doesn't convert Metaspace::space_list()->reserved_words() to >>>>> bytes, as it should. >>>>> >>>>> Note that when JDK-8024547 gets fixed, this check will be >>>>> rewritten to limit the amount of committed memory in both the >>>>> Class and NonClass metaspaces. See: >>>>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>>>> should limit the committed memory used by the metaspaces >>>>> >>>>> Testing: I've run our internal testing that sets the >>>>> MaxMetaspaceSize. >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From john.coomes at oracle.com Thu Sep 19 11:00:22 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 18:00:22 +0000 Subject: hg: hsx/hotspot-main/langtools: 39 new changesets Message-ID: <20130919180227.4FA5562974@hg.openjdk.java.net> Changeset: 23f0f3c9c44a Author: jjg Date: 2013-08-29 19:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/23f0f3c9c44a 8023833: Replace direct use of AnnotatedType in javadoc code Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java Changeset: 240f424cc0d5 Author: jjg Date: 2013-08-30 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/240f424cc0d5 8023700: Use non breaking space in various labels Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 3dd40e5715fb Author: jjg Date: 2013-08-30 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3dd40e5715fb 8024093: Two *.rej files checked in to langtools/test directory Reviewed-by: mchung - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej Changeset: dd64288f5659 Author: bpatel Date: 2013-08-30 15:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dd64288f5659 7198273: RFE : Javadoc Accessibility : Hyperlinks should contain text or an image with alt text Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java Changeset: 7a2fe98cb0e6 Author: bpatel Date: 2013-08-30 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7a2fe98cb0e6 8015882: Javadoc prints NPE when using Taglet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! test/com/sun/javadoc/testLegacyTaglet/C.java + test/com/sun/javadoc/testLegacyTaglet/Check.java ! test/com/sun/javadoc/testLegacyTaglet/TestLegacyTaglet.java Changeset: f050c714b556 Author: jjg Date: 2013-08-30 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f050c714b556 8008367: Sub-packages missing from Profiles javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: b25e387481dc Author: bpatel Date: 2013-08-30 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b25e387481dc 8022738: doclet should only generate functional interface text if source >= 8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg1/FuncInf.java Changeset: 7993cfab8610 Author: jjg Date: 2013-08-30 17:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7993cfab8610 8015663: Need to supply tests to provide javadoc for profiles support code coverage Reviewed-by: jjg Contributed-by: evgeniya.stepanova at oracle.com ! test/com/sun/javadoc/testProfiles/TestProfiles.java + test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java ! test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/ClassError.java + test/com/sun/javadoc/testProfiles/pkg2/ClassException.java + test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java + test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java ! test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt Changeset: 4a6acc42c3a1 Author: vromero Date: 2013-09-02 22:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4a6acc42c3a1 8016177: structural most specific and stuckness Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/Diagnostics/compressed/T8012003c.out ! test/tools/javac/diags/examples/BadArgTypesInLambda.java - test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java + test/tools/javac/diags/examples/PotentiallyAmbiguousOverload.java + test/tools/javac/lambda/8016177/T8016177a.java + test/tools/javac/lambda/8016177/T8016177a.out + test/tools/javac/lambda/8016177/T8016177b.java + test/tools/javac/lambda/8016177/T8016177b.out + test/tools/javac/lambda/8016177/T8016177c.java + test/tools/javac/lambda/8016177/T8016177c.out + test/tools/javac/lambda/8016177/T8016177d.java + test/tools/javac/lambda/8016177/T8016177e.java + test/tools/javac/lambda/8016177/T8016177f.java + test/tools/javac/lambda/8016177/T8016177g.java + test/tools/javac/lambda/8016177/T8016177g.out ! test/tools/javac/lambda/BadRecovery.out ! test/tools/javac/lambda/ErroneousLambdaExpr.java + test/tools/javac/lambda/ErroneousLambdaExpr.out ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference23.out ! test/tools/javac/lambda/MethodReference41.java + test/tools/javac/lambda/MethodReference41.out ! test/tools/javac/lambda/MethodReference42.java + test/tools/javac/lambda/MethodReference42.out ! test/tools/javac/lambda/MethodReference43.java + test/tools/javac/lambda/MethodReference43.out ! test/tools/javac/lambda/MethodReference44.java + test/tools/javac/lambda/MethodReference44.out ! test/tools/javac/lambda/MethodReference46.java + test/tools/javac/lambda/MethodReference46.out ! test/tools/javac/lambda/MethodReference47.java ! test/tools/javac/lambda/MethodReference47.out ! test/tools/javac/lambda/MethodReference48.java + test/tools/javac/lambda/MethodReference48.out ! test/tools/javac/lambda/MethodReference70.out ! test/tools/javac/lambda/MethodReference71.out ! test/tools/javac/lambda/MostSpecific04.java + test/tools/javac/lambda/MostSpecific04.out ! test/tools/javac/lambda/MostSpecific05.java + test/tools/javac/lambda/MostSpecific05.out ! test/tools/javac/lambda/MostSpecific08.java + test/tools/javac/lambda/MostSpecific08.out ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType02.java + test/tools/javac/lambda/TargetType02.out ! test/tools/javac/lambda/TargetType10.java - test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType24.java ! test/tools/javac/lambda/TargetType24.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/TargetType66.java ! test/tools/javac/lambda/TargetType66.out ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java - test/tools/javac/lambda/typeInference/InferenceTest5.java + test/tools/javac/lambda/typeInference/InferenceTest6.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java Changeset: 2bf4c132bf90 Author: vromero Date: 2013-09-02 22:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2bf4c132bf90 8022162: Incorrect signature determination for certain inner class generics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java Changeset: fb5a846c4a49 Author: vromero Date: 2013-09-03 23:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fb5a846c4a49 8023389: Javac fails to infer type for lambda used with intersection type and wildcards Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/8023389/T8023389.java Changeset: 9be0afbdf244 Author: vromero Date: 2013-09-03 23:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9be0afbdf244 8023545: Misleading error message when using diamond operator with private constructor Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8023545/MisleadingErrorMsgDiamondPlusPrivateCtorTest.java + test/tools/javac/T8023545/MisleadingErrorMsgDiamondPlusPrivateCtorTest.out Changeset: 438547d895dc Author: vromero Date: 2013-09-04 00:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/438547d895dc 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/MrefInferAndExplicitParams.java + test/tools/javac/lambda/8023549/T8023549.java + test/tools/javac/lambda/8023549/T8023549.out Changeset: b94824ddcbb6 Author: vromero Date: 2013-09-04 11:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b94824ddcbb6 8008275: javac.Main should be @Supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java Changeset: 044721d4d359 Author: jjg Date: 2013-09-04 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/044721d4d359 8024288: javadoc generated-by comment should always be present Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java Changeset: a76c663a9cac Author: jfranck Date: 2013-09-05 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a76c663a9cac 8023974: Drop 'implements Completer' and 'implements SourceCompleter' from ClassReader resp. JavaCompiler. Reviewed-by: jjg, jfranck Contributed-by: Andreas Lundblad ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java Changeset: e32a8a29643a Author: bpatel Date: 2013-09-05 16:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e32a8a29643a 8023608: method grouping tabs folding issue Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: 7c7b4aea6d50 Author: vromero Date: 2013-09-06 09:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7c7b4aea6d50 8024039: javac, previous solution for JDK-8022186 was incorrect Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java Changeset: 64328fe5e4a6 Author: jjg Date: 2013-09-06 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/64328fe5e4a6 8024434: problem running javadoc tests in samevm mode on Windows Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! test/tools/javadoc/api/basic/APITest.java ! test/tools/javadoc/api/basic/GetTask_FileManagerTest.java Changeset: c9d6f4749f87 Author: lana Date: 2013-09-06 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c9d6f4749f87 Merge Changeset: e84587462a47 Author: lana Date: 2013-09-06 17:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e84587462a47 Merge Changeset: 2de3750d65a5 Author: vromero Date: 2013-09-08 11:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2de3750d65a5 8024398: javac, compiler crashes with try with empty body Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8024398/NPETryTest.java Changeset: 6cffcd15a17e Author: jfranck Date: 2013-09-09 09:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6cffcd15a17e 8022260: Rename javac.code.Annotations to javac.code.SymbolMetadata Reviewed-by: jfranck, jjg Contributed-by: Andreas Lundblad - src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java + src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! test/tools/javac/lib/DPrinter.java Changeset: a4b9a8859e58 Author: vromero Date: 2013-09-09 16:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a4b9a8859e58 8024154: Fix for 8016177: structural most specific and stuckness breaks 6 langtools tests Reviewed-by: jjg, jfranck ! test/tools/javac/lambda/MethodReference41.java ! test/tools/javac/lambda/MethodReference41.out ! test/tools/javac/lambda/MethodReference42.java ! test/tools/javac/lambda/MethodReference42.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/MethodReference43.out ! test/tools/javac/lambda/MethodReference44.java ! test/tools/javac/lambda/MethodReference44.out ! test/tools/javac/lambda/MethodReference46.java ! test/tools/javac/lambda/MethodReference46.out ! test/tools/javac/lambda/MethodReference48.java ! test/tools/javac/lambda/MethodReference48.out Changeset: f4efd6ef6e80 Author: emc Date: 2013-09-09 16:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f4efd6ef6e80 8022322: Reject default and static methods in annotation Summary: Causes javac to reject static and default method declarations inside an annotation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/neg/NoDefault.java + test/tools/javac/annotations/neg/NoDefault.out + test/tools/javac/annotations/neg/NoDefaultAbstract.java + test/tools/javac/annotations/neg/NoDefaultAbstract.out + test/tools/javac/annotations/neg/NoStatic.java + test/tools/javac/annotations/neg/NoStatic.out + test/tools/javac/annotations/neg/NoStaticAbstract.java + test/tools/javac/annotations/neg/NoStaticAbstract.out Changeset: 67c5110c60fe Author: emc Date: 2013-09-09 17:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/67c5110c60fe 8015322: Javac template test framework Summary: Putback of the javac template test framework from the Lambda repository Reviewed-by: jjg Contributed-by: brian.goetz at oracle.com ! README + test/lib/combo/TEST.properties + test/lib/combo/tools/javac/combo/Diagnostics.java + test/lib/combo/tools/javac/combo/JavacTemplateTestBase.java + test/lib/combo/tools/javac/combo/Template.java + test/lib/combo/tools/javac/combo/TemplateTest.java + test/tools/javac/lambda/bridge/template_tests/BridgeMethodTestCase.java + test/tools/javac/lambda/bridge/template_tests/BridgeMethodsTemplateTest.java + test/tools/javac/lambda/bridge/template_tests/TEST.properties Changeset: 7439356a7dc5 Author: jjg Date: 2013-09-09 17:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7439356a7dc5 8006972: jtreg test fails: test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java Reviewed-by: darcy ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref Changeset: 77d395862700 Author: jlahoda Date: 2013-09-09 23:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/77d395862700 8019521: Enhanced rethrow disabled in lambdas Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas Reviewed-by: mcimadamore, jjg ! 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/lambda/EffectivelyFinalThrows.java Changeset: bb7271e64ef6 Author: jfranck Date: 2013-09-10 13:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bb7271e64ef6 8005222: Fixed bugs should have tests with bugid in @bug tag Reviewed-by: jfranck, jjg Contributed-by: Andreas Lundblad ! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java ! test/tools/javac/defaultMethods/Neg01.java ! test/tools/javac/defaultMethods/Neg02.java ! test/tools/javac/defaultMethods/Neg03.java ! test/tools/javac/defaultMethods/Neg04.java ! test/tools/javac/defaultMethods/Neg05.java ! test/tools/javac/defaultMethods/Neg06.java ! test/tools/javac/defaultMethods/Neg07.java ! test/tools/javac/defaultMethods/Neg08.java ! test/tools/javac/defaultMethods/Neg09.java ! test/tools/javac/defaultMethods/Neg10.java ! test/tools/javac/defaultMethods/Neg11.java ! test/tools/javac/defaultMethods/Neg12.java ! test/tools/javac/defaultMethods/Neg13.java ! test/tools/javac/defaultMethods/Neg14.java ! test/tools/javac/defaultMethods/Neg15.java ! test/tools/javac/defaultMethods/Neg16.java ! test/tools/javac/defaultMethods/Pos01.java ! test/tools/javac/defaultMethods/Pos02.java ! test/tools/javac/defaultMethods/Pos04.java ! test/tools/javac/defaultMethods/Pos05.java ! test/tools/javac/defaultMethods/Pos06.java ! test/tools/javac/defaultMethods/Pos07.java ! test/tools/javac/defaultMethods/Pos08.java ! test/tools/javac/defaultMethods/Pos10.java ! test/tools/javac/defaultMethods/Pos11.java ! test/tools/javac/defaultMethods/Pos12.java ! test/tools/javac/defaultMethods/Pos13.java ! test/tools/javac/defaultMethods/Pos14.java ! test/tools/javac/defaultMethods/Pos15.java ! test/tools/javac/defaultMethods/Pos16.java ! test/tools/javac/defaultMethods/TestDefaultBody.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/defaultMethods/crossCompile/CrossCompile.java ! test/tools/javac/defaultMethods/separate/Separate.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/lambda/EffectivelyFinalTest.java Changeset: d87f017ec217 Author: mcimadamore Date: 2013-09-10 16:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d87f017ec217 8024414: javac, should facilitate the use of the bootstrap compiler for debugging Reviewed-by: jjg ! make/netbeans/langtools/build.xml ! make/tools/anttasks/SelectToolTask.java Changeset: 65c218b25b61 Author: emc Date: 2013-09-11 08:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/65c218b25b61 8024510: lib/combo/tools/javac/combo/TemplateTest.java fails Summary: Edit regex in Template to allow "MAJOR." pattern. Reviewed-by: briangoetz ! test/lib/combo/tools/javac/combo/Template.java Changeset: cf37c3775397 Author: bpatel Date: 2013-09-11 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cf37c3775397 8015496: Information that package is deprecated is missing in profiles view Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java + test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt Changeset: 5d2d484a1216 Author: emc Date: 2013-09-12 14:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5d2d484a1216 8013846: javac fails to reject semantically equivalent generic method declarations Summary: Cause javac to consider intersection types with the same elements to be equal regardless of order. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/neg/OrderedIntersections.java + test/tools/javac/generics/neg/OrderedIntersections.out Changeset: 3ae1814f7c59 Author: vromero Date: 2013-09-12 22:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3ae1814f7c59 8023558: Javac creates invalid bootstrap methods for complex lambda/methodref case Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com, vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/8023558/T8023558a.java + test/tools/javac/lambda/8023558/T8023558b.java + test/tools/javac/lambda/8023558/T8023558c.java Changeset: 03c26c60499c Author: vromero Date: 2013-09-14 15:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/03c26c60499c 8024207: javac crash in Flow.AssignAnalyzer.visitIdent Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8024207/FlowCrashTest.java + test/tools/javac/T8024207/FlowCrashTest.out Changeset: 4932bb04c4b8 Author: vromero Date: 2013-09-14 19:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4932bb04c4b8 7047734: javac, the LVT is not generated correctly in several scenarios Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java + src/share/classes/com/sun/tools/javac/jvm/LVTRanges.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/Bits.java + test/tools/javac/flow/AliveRanges.java + test/tools/javac/flow/LVTHarness.java + test/tools/javac/flow/tests/TestCaseConditional.java + test/tools/javac/flow/tests/TestCaseDoLoop.java + test/tools/javac/flow/tests/TestCaseFor.java + test/tools/javac/flow/tests/TestCaseForEach.java + test/tools/javac/flow/tests/TestCaseIf.java + test/tools/javac/flow/tests/TestCaseIfElse.java + test/tools/javac/flow/tests/TestCaseSwitch.java + test/tools/javac/flow/tests/TestCaseTry.java + test/tools/javac/flow/tests/TestCaseWhile.java Changeset: 4ce8148ffc4f Author: jlahoda Date: 2013-09-16 14:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4ce8148ffc4f 8021112: Spurious unchecked warning reported by javac 6480588: No way to suppress deprecation warnings when implementing deprecated interface Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/depDocComment/SuppressDeprecation.out ! test/tools/javac/warnings/6594914/T6594914a.out ! test/tools/javac/warnings/6594914/T6594914b.out + test/tools/javac/warnings/suppress/ImplicitTest.java + test/tools/javac/warnings/suppress/ImplicitTest.out + test/tools/javac/warnings/suppress/PackageInfo.java + test/tools/javac/warnings/suppress/PackageInfo.out + test/tools/javac/warnings/suppress/T6480588.java + test/tools/javac/warnings/suppress/T6480588.out + test/tools/javac/warnings/suppress/T8021112a.java + test/tools/javac/warnings/suppress/T8021112b.java + test/tools/javac/warnings/suppress/T8021112b.out + test/tools/javac/warnings/suppress/TypeAnnotations.java + test/tools/javac/warnings/suppress/TypeAnnotations.out + test/tools/javac/warnings/suppress/VerifySuppressWarnings.java + test/tools/javac/warnings/suppress/pack/DeprecatedClass.java + test/tools/javac/warnings/suppress/pack/ImplicitMain.java + test/tools/javac/warnings/suppress/pack/ImplicitUse.java + test/tools/javac/warnings/suppress/pack/package-info.java Changeset: 252f872b8a2f Author: lana Date: 2013-09-17 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/252f872b8a2f Merge - src/share/classes/com/sun/tools/javac/code/Annotations.java - test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej - test/tools/javac/lambda/TargetType10.out - test/tools/javac/lambda/typeInference/InferenceTest5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out Changeset: 8ecfe6a3ba4c Author: cl Date: 2013-09-19 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8ecfe6a3ba4c Added tag jdk8-b108 for changeset 252f872b8a2f ! .hgtags From john.coomes at oracle.com Thu Sep 19 11:02:43 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 18:02:43 +0000 Subject: hg: hsx/hotspot-main/nashorn: 21 new changesets Message-ID: <20130919180307.606EA62975@hg.openjdk.java.net> Changeset: b5ff11e00050 Author: sundar Date: 2013-09-04 14:29 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b5ff11e00050 8024120: Setting __proto__ to null removes the __proto__ property Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! test/script/basic/JDK-8023368.js ! test/script/basic/JDK-8023368.js.EXPECTED + test/script/basic/JDK-8024120.js ! test/script/basic/circular_proto.js ! test/script/basic/nonextensible_proto_assign.js Changeset: e43ab4062636 Author: sundar Date: 2013-09-04 19:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e43ab4062636 8024174: Setting __proto__ property in Object literal should be supported Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8024174.js Changeset: 9e4acaa1bb7e Author: lana Date: 2013-09-06 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9e4acaa1bb7e Merge Changeset: 7ae169639485 Author: sundar Date: 2013-09-05 21:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7ae169639485 8024255: When a keyword is used as object property name, the property can not be deleted Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8024255.js Changeset: c3b6ce7b74bf Author: sundar Date: 2013-09-09 20:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c3b6ce7b74bf 8024180: Incorrect handling of expression and parent scope in 'with' statements Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/8024180/global_var_delete.js + test/script/basic/8024180/global_var_delete.js.EXPECTED + test/script/basic/8024180/global_var_shadow.js + test/script/basic/8024180/global_var_shadow.js.EXPECTED + test/script/basic/8024180/scope_no_such_prop.js + test/script/basic/8024180/scope_no_such_prop.js.EXPECTED + test/script/basic/8024180/with_expr_prop_add.js + test/script/basic/8024180/with_expr_prop_add.js.EXPECTED + test/script/basic/8024180/with_expr_proto_prop_add.js + test/script/basic/8024180/with_expr_proto_prop_add.js.EXPECTED + test/script/basic/8024180/with_java_object.js + test/script/basic/8024180/with_java_object.js.EXPECTED ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 1eca380a221f Author: sundar Date: 2013-09-09 20:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1eca380a221f Merge Changeset: b6c7cd8b962b Author: jlaskey Date: 2013-09-09 13:35 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b6c7cd8b962b 8024397: Nashorn FX Libraries need to be finalized. Reviewed-by: sundar, hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/base.js ! src/jdk/nashorn/internal/runtime/resources/fx/fxml.js ! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js ! src/jdk/nashorn/internal/runtime/resources/fx/media.js ! src/jdk/nashorn/internal/runtime/resources/fx/swing.js ! src/jdk/nashorn/internal/runtime/resources/fx/swt.js ! src/jdk/nashorn/internal/runtime/resources/fx/web.js Changeset: 483b42e56da4 Author: jlaskey Date: 2013-09-10 14:21 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/483b42e56da4 8024539: FX Libraries update missing file Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/controls.js Changeset: badf750dda21 Author: attila Date: 2013-09-11 10:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/badf750dda21 8024130: We no longer need slots for temporaries in self-assign indices Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java Changeset: 2d4c8fa8a5f4 Author: sundar Date: 2013-09-11 20:49 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2d4c8fa8a5f4 8024615: Refactor ScriptObjectMirror and JSObject to support external JSObject implementations Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java + src/jdk/nashorn/internal/runtime/arrays/JSObjectIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseJSObjectIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java - src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 66db7354e7e2 Author: sundar Date: 2013-09-11 22:51 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/66db7354e7e2 8024644: PluggableJSObject.iteratingJSObjectTest fails with jdk8-tl build Reviewed-by: jlaskey, hannesw ! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java Changeset: aa86166c6770 Author: sundar Date: 2013-09-11 22:53 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/aa86166c6770 Merge - src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java - src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java Changeset: e60f6add90d7 Author: hannesw Date: 2013-09-12 14:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e60f6add90d7 8024476: Octane regression on Richards Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/runtime/JSType.java Changeset: 572a2e50ba9e Author: hannesw Date: 2013-09-12 17:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/572a2e50ba9e 8024512: Regex /[^\[]/ doesn't match Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8024512.js + test/script/basic/JDK-8024512.js.EXPECTED Changeset: 917b16e509bd Author: sundar Date: 2013-09-12 22:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/917b16e509bd 8024693: Various minor issues with JSONWriter used by script parser API Reviewed-by: jlaskey, hannesw ! make/build.xml ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! test/script/basic/NASHORN-737.js ! test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/parser/assignmentExpr.js + test/script/basic/parser/assignmentExpr.js.EXPECTED + test/script/basic/parser/binaryExpr.js + test/script/basic/parser/binaryExpr.js.EXPECTED + test/script/basic/parser/breakStat.js + test/script/basic/parser/breakStat.js.EXPECTED + test/script/basic/parser/condExpr.js + test/script/basic/parser/condExpr.js.EXPECTED + test/script/basic/parser/continueStat.js + test/script/basic/parser/continueStat.js.EXPECTED + test/script/basic/parser/debuggerStat.js + test/script/basic/parser/debuggerStat.js.EXPECTED + test/script/basic/parser/functions.js + test/script/basic/parser/functions.js.EXPECTED + test/script/basic/parser/ifStat.js + test/script/basic/parser/ifStat.js.EXPECTED + test/script/basic/parser/labelledStat.js + test/script/basic/parser/labelledStat.js.EXPECTED + test/script/basic/parser/lhsExpr.js + test/script/basic/parser/lhsExpr.js.EXPECTED + test/script/basic/parser/loopStat.js + test/script/basic/parser/loopStat.js.EXPECTED + test/script/basic/parser/objectLitExpr.js + test/script/basic/parser/objectLitExpr.js.EXPECTED + test/script/basic/parser/parenExpr.js + test/script/basic/parser/parenExpr.js.EXPECTED + test/script/basic/parser/primaryExpr.js + test/script/basic/parser/primaryExpr.js.EXPECTED + test/script/basic/parser/returnStat.js + test/script/basic/parser/returnStat.js.EXPECTED + test/script/basic/parser/switchStat.js + test/script/basic/parser/switchStat.js.EXPECTED + test/script/basic/parser/throwStat.js + test/script/basic/parser/throwStat.js.EXPECTED + test/script/basic/parser/tryCatchStat.js + test/script/basic/parser/tryCatchStat.js.EXPECTED + test/script/basic/parser/unaryExpr.js + test/script/basic/parser/unaryExpr.js.EXPECTED + test/script/basic/parser/useStrict.js + test/script/basic/parser/useStrict.js.EXPECTED + test/script/basic/parser/util.js + test/script/basic/parser/varDecl.js + test/script/basic/parser/varDecl.js.EXPECTED + test/script/basic/parser/withStat.js + test/script/basic/parser/withStat.js.EXPECTED Changeset: 8b0914b25430 Author: sundar Date: 2013-09-13 16:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8b0914b25430 8024619: JDBC java.sql.DriverManager is not usable from JS script Reviewed-by: jlaskey, lagergren, attila ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java + test/script/basic/JDK-8024619.js + test/src/META-INF/services/java.sql.Driver + test/src/jdk/nashorn/api/NashornSQLDriver.java Changeset: 5683eca2967a Author: sundar Date: 2013-09-13 17:50 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5683eca2967a Merge Changeset: 38378024a332 Author: sundar Date: 2013-09-16 15:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/38378024a332 8024847: Java.to should accept mirror and external JSObjects as array-like objects as well Reviewed-by: hannesw, attila, lagergren ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java + src/jdk/nashorn/internal/runtime/JSObjectListAdapter.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java + src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + test/script/basic/JDK-8024847.js + test/script/basic/JDK-8024847.js.EXPECTED Changeset: f1fd5f0bc84c Author: attila Date: 2013-09-16 14:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f1fd5f0bc84c 8024846: keep separate internal arguments variable Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8024846.js Changeset: 445ad3f6d3b4 Author: lana Date: 2013-09-17 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/445ad3f6d3b4 Merge - src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java - src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java Changeset: 6ec2f9e5ed5b Author: cl Date: 2013-09-19 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6ec2f9e5ed5b Added tag jdk8-b108 for changeset 445ad3f6d3b4 ! .hgtags From john.coomes at oracle.com Thu Sep 19 10:35:25 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 19 Sep 2013 17:35:25 +0000 Subject: hg: hsx/hotspot-main/jdk: 96 new changesets Message-ID: <20130919175655.7BCBF62972@hg.openjdk.java.net> Changeset: 12ac08d79c9b Author: vadim Date: 2013-08-23 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12ac08d79c9b 8023052: JVM crash in native layout Reviewed-by: bae, prr ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: b5c5cff52455 Author: lana Date: 2013-08-28 08:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b5c5cff52455 Merge Changeset: 7da90f645a63 Author: jgodinez Date: 2013-08-30 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7da90f645a63 8017469: [macosx] Printing problem using ja and zh_CN locales Reviewed-by: prr, jchen ! src/macosx/native/sun/awt/CTextPipe.m Changeset: dc09174469ef Author: prr Date: 2013-08-30 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dc09174469ef 4673406: RFE: Java Printing: Provide a way to display win32 printer driver's dialog Reviewed-by: jgodinez, bae + src/share/classes/sun/print/DocumentPropertiesUI.java + src/share/classes/sun/print/PrinterJobWrapper.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/print/Win32MediaTray.java ! src/windows/classes/sun/print/Win32PrintService.java ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_PrintControl.h ! src/windows/native/sun/windows/awt_PrintJob.cpp Changeset: 2114b624bf63 Author: ceisserer Date: 2013-09-01 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2114b624bf63 7189452: XRender pipeline does ignore source-surface offset for text rendering Reviewed-by: prr, bae ! src/solaris/classes/sun/font/XRTextRenderer.java ! src/solaris/classes/sun/java2d/xr/XRBackendNative.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: a07c907a82b5 Author: bae Date: 2013-09-04 12:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a07c907a82b5 7043064: sun/java2d/cmm/ tests failed against RI b141 & b138-nightly Reviewed-by: prr, vadim ! make/sun/cmm/lcms/mapfile-vers ! makefiles/mapfiles/liblcms/mapfile-vers ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/color/ICC_ProfileGray.java ! src/share/classes/java/awt/color/ICC_ProfileRGB.java ! src/share/classes/sun/java2d/cmm/CMSManager.java ! src/share/classes/sun/java2d/cmm/PCMM.java + src/share/classes/sun/java2d/cmm/Profile.java ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java + src/share/classes/sun/java2d/cmm/lcms/LCMSProfile.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java Changeset: c561115d697d Author: ceisserer Date: 2013-09-04 12:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c561115d697d 7159455: Nimbus scrollbar rendering glitch with xrender enabled on i945GM Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java Changeset: 0a317fc785fb Author: ceisserer Date: 2013-09-05 11:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a317fc785fb 8024261: xrender: improve performance of small fillRect operations Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: 2d223e1a9706 Author: lana Date: 2013-09-06 18:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d223e1a9706 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 08296c2d4c68 Author: bae Date: 2013-09-10 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/08296c2d4c68 8024511: Crash during color profile destruction Reviewed-by: vadim, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ProfileOp/DisposalCrashTest.java Changeset: 1579407c0a82 Author: bae Date: 2013-09-13 20:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1579407c0a82 8024697: Fix for 8020983 causes Xcheck:jni warnings Reviewed-by: prr, jchen ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java Changeset: da6cd0247b27 Author: lana Date: 2013-09-17 08:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da6cd0247b27 Merge Changeset: cdf68747b0fb Author: xuelei Date: 2013-08-29 18:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cdf68747b0fb 8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII Reviewed-by: michaelm ! src/share/classes/java/net/IDN.java + test/java/net/IDN/UseSTD3ASCIIRules.java Changeset: 2d51653d9b4b Author: sjiang Date: 2013-08-30 12:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d51653d9b4b 6566891: RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed Reviewed-by: egahlin, jbachorik, dfuchs, dholmes ! src/share/classes/javax/management/remote/rmi/RMIConnector.java + test/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java + test/javax/management/remote/mandatory/connection/RMIConnectorNullSubjectConnTest.java Changeset: 5b01c851bb1d Author: dxu Date: 2013-08-30 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b01c851bb1d 8023765: Improve MaxPathLength.java testcase and reduce its test load 7160013: java/io/File/MaxPathLength.java fails Reviewed-by: alanb ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java Changeset: ead6babac5a9 Author: xuelei Date: 2013-09-01 20:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ead6babac5a9 8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java Changeset: 441da45931fa Author: chegar Date: 2013-09-02 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/441da45931fa 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg Reviewed-by: alanb, psandoz ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java Changeset: 92d594a938ff Author: dfuchs Date: 2013-09-02 18:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92d594a938ff 8016127: NLS: logging.properties translatability recommendation 8024131: Issues with cached localizedLevelName in java.util.logging.Level Summary: This fix updates logging.properties resource bundles to follow internationalization guidelines. It also fixes a caching issue with localizedLevelName. The regression test that was added needs both fixes to pass. Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/Level.java ! src/share/classes/sun/util/logging/resources/logging.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties + test/java/util/logging/LocalizedLevelName.java Changeset: a7d463f5a5b9 Author: egahlin Date: 2013-09-02 16:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7d463f5a5b9 7172176: java/jconsole test/sun/tools/jconsole/ImmutableResourceTest.sh failing Reviewed-by: mchung, mfang ! src/share/classes/sun/tools/jconsole/Resources.java ! test/ProblemList.txt - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/sun/tools/jconsole/ResourceCheckTest.sh Changeset: 4bdbe25b1e04 Author: mduigou Date: 2013-09-03 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bdbe25b1e04 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang Reviewed-by: alanb, mchung ! test/TEST.groups Changeset: 77a8c4ad516c Author: henryjen Date: 2013-08-28 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77a8c4ad516c 8022176: Weaken contract of java.lang.AutoCloseable Reviewed-by: alanb, martin, mduigou, psandoz Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/lang/AutoCloseable.java Changeset: 3db3ae4e0853 Author: henryjen Date: 2013-09-03 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3db3ae4e0853 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos Reviewed-by: mduigou ! src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java Changeset: 2e8d51a5596b Author: henryjen Date: 2013-09-03 12:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2e8d51a5596b 8017513: Support for closeable streams 8022237: j.u.s.BaseStream.onClose() has an issue in implementation or requires spec clarification 8022572: Same exception instances thrown from j.u.stream.Stream.onClose() handlers are not listed as suppressed Summary: BaseStream implements AutoCloseable; Remove CloseableStream and DelegatingStream Reviewed-by: alanb, mduigou, psandoz Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/nio/file/Files/StreamTest.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamCloseTest.java Changeset: 5920155dd080 Author: coffeys Date: 2013-09-03 22:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5920155dd080 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar + test/com/sun/corba/transport/KeepAliveSockets.java Changeset: 06b01083ebd7 Author: henryjen Date: 2013-09-03 16:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/06b01083ebd7 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect Reviewed-by: alanb ! src/share/classes/java/lang/String.java Changeset: 2cdd1078f45b Author: dholmes Date: 2013-09-03 23:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2cdd1078f45b 8024140: [TESTBUG] Profile based regression test groups for jdk repo Reviewed-by: alanb, chegar ! test/TEST.groups Changeset: 4bdbd1fabea4 Author: rfield Date: 2013-09-03 21:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bdbd1fabea4 8008688: Make MethodHandleInfo public Summary: A major overhaul to MethodHandleInfo and method handles in general. Reviewed-by: vlivanov, twisti Contributed-by: john.r.rose at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + src/share/classes/java/lang/invoke/InfoFromMemberName.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! test/java/lang/invoke/7087570/Test7087570.java + test/java/lang/invoke/RevealDirectTest.java + test/java/lang/invoke/jtreg.security.policy Changeset: 462c5589bc1a Author: psandoz Date: 2013-08-12 12:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/462c5589bc1a 8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes Summary: Use explicit lambda due to javac simplfying rules for overload resolution with implicit lambdas Reviewed-by: alanb, mduigou ! test/java/util/Arrays/SetAllTest.java Changeset: d62c911aebbb Author: psandoz Date: 2013-09-04 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d62c911aebbb 8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black) 8012913: LinkedHashMap key/value/entry spliterators should report ORDERED Reviewed-by: mduigou, forax, bchristi, alanb Contributed-by: Doug Lea
, Paul Sandoz ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/LinkedHashMap.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/util/Map/CheckRandomHashSeed.java ! test/java/util/Map/InPlaceOpsCollisions.java + test/java/util/Map/MapBinToFromTreeTest.java - test/java/util/Map/TreeBinSplitBackToEntries.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java Changeset: 336784cd60c3 Author: alanb Date: 2013-09-04 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/336784cd60c3 8008981: Deprecate SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess Reviewed-by: anthony, art, mchung ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java + test/java/awt/security/Permissions.java Changeset: ac6e99af2056 Author: dfuchs Date: 2013-09-04 15:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac6e99af2056 6823527: java.util.logging.Handler has thread safety issues Reviewed-by: dholmes, mchung ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: b3d6953b9829 Author: dfuchs Date: 2013-09-04 16:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3d6953b9829 8019853: Break logging and AWT circular dependency Summary: Break logging and AWT circular dependency, which was at the root cause for 8023258 - Logger.getLogger() after ImageIO.read() returns different logger instance Reviewed-by: mchung, art ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! test/java/util/logging/TestAppletLoggerContext.java + test/java/util/logging/TestLoggingWithMainAppContext.java Changeset: 478afc30679b Author: sherman Date: 2013-09-04 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/478afc30679b 6341345: (spec) Console.reader() should make it clear that the reader requires line termination Summary: to clarify the spec Reviewed-by: alanb ! src/share/classes/java/io/Console.java Changeset: c6a4df06d57e Author: sherman Date: 2013-09-04 12:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6a4df06d57e 7186632: NLS t13y issue on jar.properties file Summary: to remove the redundant backslash Reviewed-by: naoto ! src/share/classes/sun/tools/jar/resources/jar.properties Changeset: bd6fcc5eebb8 Author: rfield Date: 2013-09-04 19:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd6fcc5eebb8 8020816: Metafactory crashes on code with method reference 8021050: MethodHandleInfo throws exception when method handle is to a method with @CallerSensitive Summary: Fixed by 8008688 - this is a test to confirm the above fixed Reviewed-by: vlivanov + test/jdk/lambda/MethodReferenceTestCallerSensitive.java Changeset: af1b08ff48ae Author: jbachorik Date: 2013-09-05 13:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af1b08ff48ae 8023464: test/closed/sun/tracing/ProviderProxyTest.java failing Summary: Don't rely on assertions when an Exception suits better Reviewed-by: alanb, dfuchs, sjiang ! src/share/classes/sun/tracing/ProviderSkeleton.java Changeset: 9522b5e836d3 Author: jbachorik Date: 2013-09-05 14:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9522b5e836d3 8004179: Few of test/java/lang/management/ThreadMXBean/* tests don't clean up the created threads Summary: Just run those tests in "othervm" mode. Reviewed-by: alanb, dfuchs, sjiang ! test/java/lang/management/ThreadMXBean/LockedMonitors.java ! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java ! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java ! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java ! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java Changeset: 4c711ef41bfa Author: naoto Date: 2013-09-05 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4c711ef41bfa 8023943: Method description fix for String.toLower/UpperCase() methods Reviewed-by: okutsu ! src/share/classes/java/lang/String.java Changeset: 9cc74675a854 Author: rfield Date: 2013-09-05 14:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9cc74675a854 8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError Summary: Fix pre-existing 292 bug tickled by combo of nashorn code and MethodHandleInfo changes Reviewed-by: jrose Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: f2487bb0c0d2 Author: rfield Date: 2013-09-06 00:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2487bb0c0d2 8024260: 10 closed/java/lang/invoke/* tests failing after overhaul to MethodHandleInfo Reviewed-by: vlivanov, briangoetz Contributed-by: john.r.rose at oracle.com ! src/share/classes/java/lang/invoke/MethodHandle.java Changeset: da9de6f5cd6f Author: jbachorik Date: 2013-09-06 10:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da9de6f5cd6f 6815130: Intermittent ThreadMXBean/Locks.java test failure Summary: Preventing stale reads from ThreadExecutionSynchronizer.waiting flag Reviewed-by: dholmes, mchung, dfuchs ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java Changeset: 2064b2077a62 Author: jfranck Date: 2013-09-06 14:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2064b2077a62 5047859: (reflect) Class.getField can't find String[].length Reviewed-by: darcy, mchung ! src/share/classes/java/lang/Class.java + test/java/lang/Class/getField/ArrayLength.java Changeset: 0aba8b6232af Author: mullan Date: 2013-09-06 12:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0aba8b6232af 8023362: Don't allow soft-fail behavior if OCSP responder returns "unauthorized" Reviewed-by: vinnie, xuelei ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java + test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java Changeset: f23a84a1cf8e Author: mullan Date: 2013-09-06 12:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f23a84a1cf8e Merge - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: 257de3e3a278 Author: lana Date: 2013-09-06 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/257de3e3a278 Merge Changeset: 0f47f9f622d9 Author: xuelei Date: 2013-09-07 17:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0f47f9f622d9 7188657: There should be a way to reorder the JSSE ciphers Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java Changeset: 6bfabb71ae1e Author: weijun Date: 2013-09-09 11:08 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6bfabb71ae1e 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc* Reviewed-by: xuelei ! test/sun/security/krb5/runNameEquals.sh Changeset: 4afdf10de648 Author: dfuchs Date: 2013-09-09 13:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4afdf10de648 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship 8021003: java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java fails intermittently 8019945: test/java/util/logging/LogManagerInstanceTest.java failing intermittently Summary: This fix untangles the class initialization of Logger and LogManager, and also cleans up the relationship between LogManager, LoggerContext, and Logger, which were at the root cause of some intermittent test failures. Reviewed-by: mchung, martin, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java ! test/java/util/logging/Logger/getGlobal/policy ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/TestAppletLoggerContext.java Changeset: 02064634bc88 Author: msheppar Date: 2013-09-06 15:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/02064634bc88 8023326: [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally Summary: amended test to be more robust to set of potential exceptions thrown Reviewed-by: chegar, khazra ! test/java/net/CookieHandler/LocalHostCookie.java Changeset: 4fd7abaf0a5f Author: msheppar Date: 2013-09-09 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fd7abaf0a5f 8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address Summary: amended src/windows/native/java/net/NetworkInterface_winXP.c to "properly" handle Ipv6IfIndex Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface_winXP.c + test/java/net/NetworkInterface/UniqueMacAddressesTest.java Changeset: be0bcd6a904e Author: juh Date: 2013-09-09 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be0bcd6a904e 8024432: Fix doclint issues in java.security Reviewed-by: darcy, mullan ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/AlgorithmParametersSpi.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyFactorySpi.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Principal.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java ! src/share/classes/java/security/interfaces/RSAPrivateCrtKey.java ! src/share/classes/java/security/interfaces/RSAPrivateKey.java ! src/share/classes/java/security/interfaces/RSAPublicKey.java Changeset: 6731ea9123f2 Author: smarks Date: 2013-09-09 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6731ea9123f2 8023447: change specification to allow RMI activation to be optional Reviewed-by: darcy, alanb, olagneau ! src/share/classes/java/rmi/activation/Activatable.java ! src/share/classes/java/rmi/activation/ActivationDesc.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/activation/ActivationGroupID.java ! src/share/classes/java/rmi/activation/ActivationID.java ! src/share/classes/java/rmi/activation/package.html Changeset: f80b8af9c218 Author: xuelei Date: 2013-09-09 19:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f80b8af9c218 8024444: Change to use othervm mode of tests in SSLEngineImpl Reviewed-by: mullan ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java Changeset: 909aced59bef Author: alanb Date: 2013-09-10 10:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/909aced59bef 8023878: (fs) TEST_BUG java/nio/file/WatchService/SensitivityModifier.java fails intermittently Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/file/WatchService/SensitivityModifier.java Changeset: c9083205e6eb Author: xuelei Date: 2013-09-10 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9083205e6eb 8024501: sun.security.mscapi.Key has no definition of serialVersionUID Reviewed-by: weijun ! src/windows/classes/sun/security/mscapi/Key.java Changeset: 13ee370ee8b3 Author: okutsu Date: 2013-09-11 15:29 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13ee370ee8b3 8024141: Unexpected timezone display name Reviewed-by: peytoia ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/sun/util/locale/provider/Bug8024141.java Changeset: b271ea30f440 Author: jfranck Date: 2013-09-11 09:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b271ea30f440 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array types Summary: Update spec to match long standing behavior Reviewed-by: darcy, mchung ! src/share/classes/java/lang/Class.java + test/java/lang/Class/ArrayMethods.java Changeset: 517c5e99fb2f Author: chegar Date: 2013-09-11 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/517c5e99fb2f 8024508: Fix doclint issues in com.sun.nio.sctp Reviewed-by: alanb ! src/share/classes/com/sun/nio/sctp/Association.java ! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java ! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java ! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/Notification.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java Changeset: d389dedd1ccb Author: chegar Date: 2013-09-11 11:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d389dedd1ccb 8023090: Additional debug info for java/net/NetworkInterface/Equals.java Reviewed-by: alanb ! test/java/net/NetworkInterface/Equals.java Changeset: 7bfe3da4fad6 Author: naoto Date: 2013-09-11 05:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bfe3da4fad6 8024332: sun/util/resources/en split between rt.jar and localedata.jar Reviewed-by: alanb, erikj ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template Changeset: c3ef78cd9081 Author: emc Date: 2013-09-11 09:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3ef78cd9081 6962494: Update documentation on Executable.getParameterAnnotations() Summary: Update javadoc comments on getParameterAnnotations to correctly describe its behavior Reviewed-by: darcy, jfranck ! src/share/classes/java/lang/reflect/Executable.java Changeset: 1ec241501e60 Author: michaelm Date: 2013-09-11 15:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ec241501e60 8024601: Windows networking code prevents use of -Xlint:auxiliaryclass in jdk build Reviewed-by: chegar ! src/share/classes/java/net/AbstractPlainSocketImpl.java + src/share/classes/java/net/InetAddressContainer.java Changeset: 7dcb9d944910 Author: michaelm Date: 2013-09-11 15:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7dcb9d944910 Merge Changeset: 292d93f32aa1 Author: rriggs Date: 2013-09-11 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/292d93f32aa1 8024164: JSR310 serialization should be described in details Summary: The serialized-form.html should specify the stream format for interoperability Reviewed-by: alanb ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Ser.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/HijrahEra.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java ! src/share/classes/java/time/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 8b4aef582087 Author: rriggs Date: 2013-09-11 10:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b4aef582087 Merge Changeset: 60b4cbdb446d Author: sherman Date: 2013-09-11 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60b4cbdb446d 8024338: Constant fields introduced by JDK-4759491 fix in b94 are exposed as public fields in public API Summary: to move the new constants out of ZipConstants.java Reviewed-by: martin ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipConstants64.java ! src/share/classes/java/util/zip/ZipEntry.java Changeset: 70aab3db56de Author: henryjen Date: 2013-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70aab3db56de 8024500: Missing API coverage for java.util.function.BiFunction andThen Reviewed-by: mduigou, alanb + test/java/util/Collections/SingletonIterator.java + test/java/util/function/BiFunction/BiFunctionTest.java Changeset: e407df8093dc Author: sjiang Date: 2013-09-12 09:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e407df8093dc 8023529: OpenMBeanInfoSupport.equals/hashCode throw NPE Reviewed-by: dholmes, dfuchs ! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java + test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java + test/javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java Changeset: 262a625809fd Author: darcy Date: 2013-09-12 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/262a625809fd 8024643: Turn on javac lint checking in building the jdk repo Reviewed-by: erikj, ihse, smarks ! makefiles/Setup.gmk Changeset: 631c8dcd91f4 Author: dfuchs Date: 2013-09-12 17:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/631c8dcd91f4 8024525: Make Logger log methods call isLoggable() Summary: This changeset makes the various Logger logging method call isLoggable() instead of inlining the level checks. Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/isLoggable/TestIsLoggable.java Changeset: 672f349fbad7 Author: rriggs Date: 2013-09-12 10:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/672f349fbad7 8024618: Issues with French locale on compact1,2: expected: but was: Summary: Tests against the data of the French locale are not valid as conformance tests and are redundant with testing of the US Locale above Reviewed-by: alanb ! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java Changeset: 60d6f60416ca Author: lancea Date: 2013-09-12 13:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60d6f60416ca 8015340: remove erroneous @since tag Reviewed-by: darcy ! src/share/classes/java/sql/PreparedStatement.java Changeset: be6f5f027bc2 Author: henryjen Date: 2013-09-06 22:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be6f5f027bc2 8011916: Spec update for java.util.stream 8024339: j.u.s.Stream.reduce(BinaryOperator) throws unexpected NPE Reviewed-by: mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/function/package-info.java ! src/share/classes/java/util/stream/BaseStream.java ! src/share/classes/java/util/stream/Collector.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java Changeset: 917fffe971c8 Author: bpb Date: 2013-09-11 17:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/917fffe971c8 8010430: Math.round has surprising behavior for odd values of ulp 1 Summary: If the effective floating point exponent is zero return the significand including the implicit 1-bit. Reviewed-by: bpb, darcy, gls Contributed-by: Dmitry Nadezhin ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! test/java/lang/Math/RoundTests.java Changeset: ba0b95f310c8 Author: sjiang Date: 2013-09-13 10:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba0b95f310c8 8023669: MBean*Info.hashCode : NPE Reviewed-by: dholmes, dfuchs, jbachorik ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java + test/javax/management/MBeanInfo/MBeanInfoHashCodeNPETest.java Changeset: cc2bae7f8fbb Author: bchristi Date: 2013-09-12 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc2bae7f8fbb 8024009: Remove jdk.map.useRandomSeed system property Summary: Removed usage of hashSeed in Hashtable & WeakHashMap, and removed tests Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/WeakHashMap.java - test/java/util/Map/CheckRandomHashSeed.java ! test/java/util/Map/Collisions.java Changeset: c53411f89b4c Author: msheppar Date: 2013-09-13 12:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c53411f89b4c 8024675: java/net/NetworkInterface/UniqueMacAddressesTest.java fails on Windows Summary: amended test to add active, i.e. isUp(), NetworkInterfaces to test list Reviewed-by: alanb, chegar ! test/java/net/NetworkInterface/UniqueMacAddressesTest.java Changeset: c65848f2b6a1 Author: mduigou Date: 2013-09-13 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c65848f2b6a1 8021591: Additional explicit null checks Reviewed-by: psandoz, alanb ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/javax/security/auth/Subject.java ! test/java/util/Collection/CollectionDefaults.java - test/java/util/Collection/ListDefaults.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collection/testlibrary/CollectionAsserts.java ! test/java/util/Collection/testlibrary/CollectionSupplier.java + test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java + test/java/util/Collection/testlibrary/ExtendsAbstractList.java + test/java/util/Collection/testlibrary/ExtendsAbstractSet.java + test/java/util/List/ListDefaults.java ! test/java/util/Map/Defaults.java Changeset: 973fdd9506b2 Author: mduigou Date: 2013-09-13 11:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/973fdd9506b2 8024014: TEST.groups - split sub-groups for jdk_collections, jdk_stream, jdk_concurrent, jdk_util_other from jdk_util Reviewed-by: mchung, dholmes, alanb ! test/TEST.groups Changeset: 5f81a12fed4d Author: bchristi Date: 2013-09-13 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f81a12fed4d 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] Summary: On MacOS X set user.home to value of NSHomeDirectory() Reviewed-by: alanb, ddehaven, mduigou ! make/common/Defs-macosx.gmk ! make/java/java/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c Changeset: 5c7690923663 Author: lancea Date: 2013-09-13 19:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5c7690923663 8014967: EBehavior of DriverManager.registerDriver(dr) is unspecified if driver is null Reviewed-by: alanb ! src/share/classes/java/sql/DriverManager.java Changeset: a7980b099af1 Author: henryjen Date: 2013-09-06 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7980b099af1 8024825: Some fixes are missing from java.util.stream spec update Reviewed-by: mduigou ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/package-info.java Changeset: 3255a4e348a1 Author: rriggs Date: 2013-09-14 13:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3255a4e348a1 8023639: Difference between LocalTime.now(Clock.systemDefaultZone()) and LocalTime.now() executed successively is more than 100 000 000 nanoseconds for slow machines Summary: Test timed out on a slow machine; it is not a conformance test and should be in the test subtree Reviewed-by: darcy, sherman ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/test/java/time/TestLocalTime.java Changeset: 35bb1c7f227c Author: rriggs Date: 2013-09-14 13:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/35bb1c7f227c 8023556: Update javadoc for start of Meiji era Summary: correct the javadoc in JapaneseEra.MEIJI to match the implementation Reviewed-by: darcy, sherman ! src/share/classes/java/time/chrono/JapaneseEra.java ! test/java/time/test/java/time/TestLocalTime.java Changeset: ff6c76f7733e Author: psandoz Date: 2013-09-02 11:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff6c76f7733e 8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails intermittently Reviewed-by: forax, chegar, alanb Contributed-by: Doug Lea
, Peter Levart , Paul Sandoz ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! test/java/util/concurrent/ConcurrentHashMap/toArray.java Changeset: 5025ed287a4a Author: psandoz Date: 2013-09-15 16:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5025ed287a4a 8024837: Rename java/util/concurrent/ConcurrentHashMap/toArray.java to ToArray.java Reviewed-by: alanb ! test/java/util/concurrent/ConcurrentHashMap/ToArray.java < test/java/util/concurrent/ConcurrentHashMap/toArray.java Changeset: b9d59414de23 Author: sherman Date: 2013-09-15 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b9d59414de23 7186311: (props) "Unicode" is misspelled as "Uniocde" in JavaDoc and error message Summary: to correct the typo Reviewed-by: alanb, chegar ! make/tools/src/build/tools/generatecharacter/CharacterName.java ! src/share/classes/java/util/Properties.java Changeset: efa09bf27d39 Author: sherman Date: 2013-09-15 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/efa09bf27d39 8020687: Deflater.setLevel does not work as expected Summary: to clarify the api to match the existing implementation behavior Reviewed-by: alanb ! src/share/classes/java/util/zip/Deflater.java Changeset: db0fc2b71298 Author: msheppar Date: 2013-09-16 14:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db0fc2b71298 6458027: Disabling IPv6 on a specific network interface causes problems Summary: added a check to test if an interface is configured for IPv6 to native code TwoStacklainDatagramSocketImpl: getMulticastInterface, setMulticastInterface Reviewed-by: chegar, michaelm ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c + test/java/net/MulticastSocket/SetGetNetworkInterfaceTest.java Changeset: 86aa8e7503e9 Author: henryjen Date: 2013-09-16 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86aa8e7503e9 8024874: Copy-paste typo in the spec for j.u.Comparator.thenComparing(Function, Comparator) Reviewed-by: mduigou ! src/share/classes/java/util/Comparator.java Changeset: 657482758408 Author: lancea Date: 2013-09-17 07:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/657482758408 7097386: Correct error in Predicate javadoc example Reviewed-by: alanb, shade ! src/share/classes/javax/sql/rowset/Predicate.java Changeset: ebc44e50df79 Author: lana Date: 2013-09-17 08:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ebc44e50df79 Merge - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! test/ProblemList.txt - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: 5063b43d7e09 Author: vadim Date: 2013-09-12 12:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5063b43d7e09 8008022: Upgrade Direct X SDK used to build JDK Reviewed-by: erikj, prr, ihse ! make/Makefile ! make/common/Defs-windows.gmk ! make/common/Sanity.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/javax/sound/jsoundds/Makefile ! make/jdk_generic_profile.sh ! make/netbeans/awt2d/README ! make/sun/awt/Makefile ! make/sun/jawt/Makefile ! makefiles/CompileNativeLibraries.gmk Changeset: 5da2bb1419e6 Author: katleman Date: 2013-09-17 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5da2bb1419e6 Merge Changeset: 006aaa5f069e Author: katleman Date: 2013-09-17 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/006aaa5f069e Merge ! makefiles/CompileNativeLibraries.gmk Changeset: a7dd84b9557c Author: cl Date: 2013-09-19 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7dd84b9557c Added tag jdk8-b108 for changeset 006aaa5f069e ! .hgtags From lois.foltan at oracle.com Thu Sep 19 08:13:48 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 19 Sep 2013 11:13:48 -0400 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523B13F0.1040105@oracle.com> References: <523B13F0.1040105@oracle.com> Message-ID: <523B14AC.5040509@oracle.com> Please review the following fix: Webrev: http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & CheckUnhandledOops has limited usefulness now bug links at: https://bugs.openjdk.java.net/browse/JDK-7180556 https://bugs.openjdk.java.net/browse/JDK-7195622 Summary of fix: Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: 1. A review should start at understanding the changes made to oopsHierarchy.hpp a. Addition of a non-volatile copy constructor to address compile time errors reported in JDK-7180556 and also currently by g++ compilers on Linux. b. Addition of member wise assignment operators to handle many instances of [non]volatile to [non]volatile oops within the JVM. Note: Solaris compilers would not allow for the member wise assignment operators of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile assignment operator. So the g++ compilers needed these different flavors of the assignment operator and Solaris did not. d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. g++ specifically complained when trying to pass a volatile "this" pointer. e. Removal of the ambiguous behavior of having overloaded copy constructor and explicit user conversion member functions defined of both integral and void *. All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. 2. Change #1e had the consequence of C++ compilers now generating compile time errors where the practice has been to cast an oop to and from an integral type such as intptr_t. To allow for this practice to continue, when oop is a structure and not a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) by the g++ compilers on Linux and MacOS. This caused several changes to be needed throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). 4. Many instances of an assignment to a volatile oop required a "const_cast" to cast away the volatileness of the lvalue. There is already precedence for this type of change within utilities/taskqueue.hpp. The following comment was in place: // g++ complains if the volatile result of the assignment is // unused, so we cast the volatile away. We cannot cast directly // to void, because gcc treats that as not using the result of the // assignment. However, casting to E& means that we trigger an // unused-value warning. So, we cast the E& to void. 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() member functions was to accommodate the Solaris C++ compiler's complaint about the assignment of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of allowing for all flavors of volatile/non-volatile member wise assignment operators. Per Liden of the GC group did pre-review this specific change with regards to performance implications and was not concerned. 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a fastdebug build, an unresolved symbol occurred. philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed U Hashtable::_seed 0000000000848890 t Hashtable::seed() ... Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. Builds: Solaris (12u1 & 12u3 C++ compilers), MacOS (llvm-g++ & clang++ compilers), Linux (g++ v4.4.3 & g++ v4.7.3), VS2010 Tests: JTREG on MacOS, vm.quick.testlist on LInux, nsk.regression.testlist, nsk.stress.testlist on LInux, JCK vm on Windows Thank you, Lois From stefan.karlsson at oracle.com Thu Sep 19 12:48:50 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Sep 2013 21:48:50 +0200 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Message-ID: <523B5522.8020207@oracle.com> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8025096 In the fix for 'JDK-8024547 : MaxMetaspaceSize should limit the committed memory used by the metaspaces' we need to make a clearer distinction between when new memory is committed and when memory is allocated inside already committed memory. Moving the ChunkManager, which handles the free chunk list, out of the VirtualSpaceList, which handles the committed metaspace memory, is a step in that direction. Changes: - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. - Move the inc_container_count() into ChunkManager::free_chunks_get. Now the Chunk manager calls dec_container_count when chunks are inserted in the chunk free list and inc_container_count when chunks are removed from the chunk free list. - Moved the ChunkManager::chunk_freelist_allocate() call out from the VirtualSpaceList::get_new_chunk() thanks, StefanK From bengt.rutisson at oracle.com Thu Sep 19 13:55:41 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 19 Sep 2013 22:55:41 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B2DD0.1030402@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> <523B2DD0.1030402@oracle.com> Message-ID: <523B64CD.3000101@oracle.com> On 9/19/13 7:01 PM, Stefan Karlsson wrote: > On 9/19/13 5:10 PM, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> Given that we just want to get the byte/word conversion right I think >> this change is fine. The bug JDK-8024547 contains a long list of >> improvements so it is a bit difficult to tell, but the asymmetry with >> using reserved memory for NonClassType and allocated memory for >> ClassType will go away with some of the changes for JDK-8024547, right? >> >> 1345 size_t nonclass_allocated = >> MetaspaceAux::reserved_bytes(Metaspace::NonClassType); >> 1346 size_t class_allocated = >> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >> 1347 size_t real_allocated = nonclass_allocated + >> real_allocated; > > Yes. The current code we're working on calls > MetaspaceAux::committed_bytes() directly. OK. Sounds good. Then I'm fine with this change. Bengt > > StefanK >> >> Thanks, >> Bengt >> >> >> On 9/19/13 4:59 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>> >>> The following code in Metaspace::should_expand: >>> >>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> if (real_allocated >= MaxMetaspaceSize) { >>> return false; >>> } >>> >>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >>> as it should. >>> >>> Note that when JDK-8024547 gets fixed, this check will be rewritten >>> to limit the amount of committed memory in both the Class and >>> NonClass metaspaces. See: >>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces >>> >>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Thu Sep 19 14:09:54 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Sep 2013 23:09:54 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B64CD.3000101@oracle.com> References: <523B1143.8080602@oracle.com> <523B13CA.5050406@oracle.com> <523B2DD0.1030402@oracle.com> <523B64CD.3000101@oracle.com> Message-ID: <523B6822.1000207@oracle.com> On 9/19/13 10:55 PM, Bengt Rutisson wrote: > On 9/19/13 7:01 PM, Stefan Karlsson wrote: >> On 9/19/13 5:10 PM, Bengt Rutisson wrote: >>> >>> Hi Stefan, >>> >>> Given that we just want to get the byte/word conversion right I >>> think this change is fine. The bug JDK-8024547 contains a long list >>> of improvements so it is a bit difficult to tell, but the asymmetry >>> with using reserved memory for NonClassType and allocated memory for >>> ClassType will go away with some of the changes for JDK-8024547, right? >>> >>> 1345 size_t nonclass_allocated = >>> MetaspaceAux::reserved_bytes(Metaspace::NonClassType); >>> 1346 size_t class_allocated = >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> 1347 size_t real_allocated = nonclass_allocated + >>> real_allocated; >> >> Yes. The current code we're working on calls >> MetaspaceAux::committed_bytes() directly. > > OK. Sounds good. Then I'm fine with this change. Thanks, Bengt. StefanK > > Bengt > > >> >> StefanK >>> >>> Thanks, >>> Bengt >>> >>> >>> On 9/19/13 4:59 PM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>>> >>>> The following code in Metaspace::should_expand: >>>> >>>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>>> if (real_allocated >= MaxMetaspaceSize) { >>>> return false; >>>> } >>>> >>>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >>>> as it should. >>>> >>>> Note that when JDK-8024547 gets fixed, this check will be rewritten >>>> to limit the amount of committed memory in both the Class and >>>> NonClass metaspaces. See: >>>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>>> should limit the committed memory used by the metaspaces >>>> >>>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>>> >>>> thanks, >>>> StefanK >>> >> > From christian.thalinger at oracle.com Thu Sep 19 15:09:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Sep 2013 15:09:10 -0700 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523B14AC.5040509@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> Message-ID: <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) Could these two macros also be a method? On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: > > > Please review the following fix: > Webrev: > http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ > > Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & > CheckUnhandledOops has limited usefulness now bug links at: > > https://bugs.openjdk.java.net/browse/JDK-7180556 > https://bugs.openjdk.java.net/browse/JDK-7195622 > > Summary of fix: > > Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: > > 1. A review should start at understanding the changes made to oopsHierarchy.hpp > a. Addition of a non-volatile copy constructor to address compile time errors > reported in JDK-7180556 and also currently by g++ compilers on Linux. > b. Addition of member wise assignment operators to handle many instances > of [non]volatile to [non]volatile oops within the JVM. > Note: Solaris compilers would not allow for the member wise assignment operators > of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, > Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile > assignment operator. So the g++ compilers needed these different flavors > of the assignment operator and Solaris did not. > d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. > g++ specifically complained when trying to pass a volatile "this" pointer. > e. Removal of the ambiguous behavior of having overloaded copy constructor and > explicit user conversion member functions defined of both integral and void *. > All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. > > 2. Change #1e had the consequence of C++ compilers now generating compile time > errors where the practice has been to cast an oop to and from an integral type such > as intptr_t. To allow for this practice to continue, when oop is a structure and not > a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new > macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. > > 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) > by the g++ compilers on Linux and MacOS. This caused several changes to be needed > throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). > > 4. Many instances of an assignment to a volatile oop required a "const_cast" to > cast away the volatileness of the lvalue. There is already precedence for this > type of change within utilities/taskqueue.hpp. The following comment was in place: > > // g++ complains if the volatile result of the assignment is > // unused, so we cast the volatile away. We cannot cast > directly > // to void, because gcc treats that as not using the result > of the > // assignment. However, casting to E& means that we trigger an > // unused-value warning. So, we cast the E& to void. > > 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() > member functions was to accommodate the Solaris C++ compiler's complaint about the assignment > of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated > with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of > allowing for all flavors of volatile/non-volatile member wise assignment operators. > Per Liden of the GC group did pre-review this specific change with regards to performance > implications and was not concerned. > > 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation > of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a > fastdebug build, an unresolved symbol occurred. > philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed > U Hashtable::_seed > 0000000000848890 t Hashtable::seed() > ... > > Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. > > Builds: > Solaris (12u1 & 12u3 C++ compilers), > MacOS (llvm-g++ & clang++ compilers), > Linux (g++ v4.4.3 & g++ v4.7.3), > VS2010 > > Tests: > JTREG on MacOS, > vm.quick.testlist on LInux, > nsk.regression.testlist, nsk.stress.testlist on LInux, > JCK vm on Windows > > Thank you, Lois > > > > > > > > > > From christian.thalinger at oracle.com Thu Sep 19 15:27:21 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Sep 2013 15:27:21 -0700 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523B7874.4040605@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> <523B7874.4040605@oracle.com> Message-ID: <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> On Sep 19, 2013, at 3:19 PM, Lois Foltan wrote: > > On 9/19/2013 6:09 PM, Christian Thalinger wrote: >> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >> + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >> >> Could these two macros also be a method? > Hi Christian, > I assume by method you are implying methods within the oop class itself? Not necessarily. We already have a couple of inline methods is globalDefinitions.hpp. Would that work? > That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. > > Thanks for the initial review, > Lois > >> >> On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: >> >>> >>> Please review the following fix: >>> Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >>> >>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >>> CheckUnhandledOops has limited usefulness now bug links at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>> >>> Summary of fix: >>> >>> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >>> >>> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >>> a. Addition of a non-volatile copy constructor to address compile time errors >>> reported in JDK-7180556 and also currently by g++ compilers on Linux. >>> b. Addition of member wise assignment operators to handle many instances >>> of [non]volatile to [non]volatile oops within the JVM. >>> Note: Solaris compilers would not allow for the member wise assignment operators >>> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >>> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >>> assignment operator. So the g++ compilers needed these different flavors >>> of the assignment operator and Solaris did not. >>> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >>> g++ specifically complained when trying to pass a volatile "this" pointer. >>> e. Removal of the ambiguous behavior of having overloaded copy constructor and >>> explicit user conversion member functions defined of both integral and void *. >>> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >>> >>> 2. Change #1e had the consequence of C++ compilers now generating compile time >>> errors where the practice has been to cast an oop to and from an integral type such >>> as intptr_t. To allow for this practice to continue, when oop is a structure and not >>> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >>> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >>> >>> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >>> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >>> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >>> >>> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >>> cast away the volatileness of the lvalue. There is already precedence for this >>> type of change within utilities/taskqueue.hpp. The following comment was in place: >>> >>> // g++ complains if the volatile result of the assignment is >>> // unused, so we cast the volatile away. We cannot cast >>> directly >>> // to void, because gcc treats that as not using the result >>> of the >>> // assignment. However, casting to E& means that we trigger an >>> // unused-value warning. So, we cast the E& to void. >>> >>> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >>> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >>> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >>> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >>> allowing for all flavors of volatile/non-volatile member wise assignment operators. >>> Per Liden of the GC group did pre-review this specific change with regards to performance >>> implications and was not concerned. >>> >>> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >>> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >>> fastdebug build, an unresolved symbol occurred. >>> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >>> U Hashtable::_seed >>> 0000000000848890 t Hashtable::seed() >>> ... >>> >>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >>> >>> Builds: >>> Solaris (12u1 & 12u3 C++ compilers), >>> MacOS (llvm-g++ & clang++ compilers), >>> Linux (g++ v4.4.3 & g++ v4.7.3), >>> VS2010 >>> >>> Tests: >>> JTREG on MacOS, >>> vm.quick.testlist on LInux, >>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>> JCK vm on Windows >>> >>> Thank you, Lois >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > From christian.thalinger at oracle.com Thu Sep 19 16:08:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Sep 2013 16:08:24 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> Message-ID: <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> JPRT found some problems. Apparently something does #define C2 'E' on Solaris so I had to prefix all kind flags with KIND_: + // flag kind + KIND_PRODUCT = 1 << 4, + KIND_MANAGEABLE = 1 << 5, + KIND_DIAGNOSTIC = 1 << 6, + KIND_EXPERIMENTAL = 1 << 7, + KIND_NOT_PRODUCT = 1 << 8, + KIND_DEVELOP = 1 << 9, + KIND_PLATFORM_DEPENDENT = 1 << 10, + KIND_READ_WRITE = 1 << 11, + KIND_C1 = 1 << 12, + KIND_C2 = 1 << 13, + KIND_ARCH = 1 << 14, + KIND_SHARK = 1 << 15, + KIND_LP64_PRODUCT = 1 << 16, + KIND_COMMERCIAL = 1 << 17, Two other problems found by Visual Studio were a bool return: + bool Flag::get_bool() const { + if (is_constant_in_binary()) { + return _value != 0; + } else { + return *((bool*) _addr); + } + } and the size_t changes at the bottom of this file: http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html Everything else (except the renames) are the same. I tried to create an incremental webrev but I failed. Sorry. On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: > > On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: > >> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>> >>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>> >>>> Christian, >>>> >>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>> >>> Yes, good point. >>> >>>> >>>> It would be nice enumerate flag's type and use int instead of strings: >>>> >>>> enum { >>>> bool_flag = 1, >>>> intx_flag = 2, >>>> >>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>> >>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >> >> Do it in separate changes after you push this. >> And if you remove _type field later you don't need to move _flags now. >> So you can push your current changes as it is. They are good. > > Thank you, Vladimir. -- Chris > >> >> Thanks, >> Vladimir >> >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>> >>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>> >>>>>> Hi Chris, >>>>>> >>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>> >>>>>> + if (is_constant_in_binary()) { >>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>> >>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>> >>>>> Good point. I made that change: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>> >>>>>> >>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>> >>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>> >>>>>> >>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>> >>>>> The 32-bit product build also contains the server compiler. >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>> >>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>> >>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>> >>>>>>> Before: >>>>>>> >>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>> Attaching to process 9399, please wait... >>>>>>> hsdb> flags -nd >>>>>>> InitialHeapSize = 495006528 5 >>>>>>> MaxHeapSize = 7920943104 5 >>>>>>> UseCompressedKlassPointers = true 5 >>>>>>> UseCompressedOops = true 5 >>>>>>> UseParallelGC = true 5 >>>>>>> hsdb> flags InlineMathNatives >>>>>>> Couldn't find flag: InlineMathNatives >>>>>>> >>>>>>> After: >>>>>>> >>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>> Attaching to process 3726, please wait... >>>>>>> hsdb> flags -nd >>>>>>> InitialHeapSize = 495006528 5 >>>>>>> MaxHeapSize = 7920943104 5 >>>>>>> UseCompressedKlassPointers = true 5 >>>>>>> UseCompressedOops = true 5 >>>>>>> UseParallelGC = true 5 >>>>>>> hsdb> flags InlineMathNatives >>>>>>> InlineMathNatives = true 0 >>>>>>> >>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>> >>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>> >>>>>>> The output for product builds is unchanged. >>>>>>> >>>>> >>> > From christian.thalinger at oracle.com Thu Sep 19 16:25:42 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Sep 2013 16:25:42 -0700 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523B8729.8090803@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> <523B7874.4040605@oracle.com> <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> <523B8729.8090803@oracle.com> Message-ID: <28F5421A-B77B-4675-8A0A-153B0434E71A@oracle.com> On Sep 19, 2013, at 4:22 PM, Lois Foltan wrote: > > On 9/19/2013 6:27 PM, Christian Thalinger wrote: >> On Sep 19, 2013, at 3:19 PM, Lois Foltan wrote: >> >>> On 9/19/2013 6:09 PM, Christian Thalinger wrote: >>>> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>> + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>> >>>> Could these two macros also be a method? >>> Hi Christian, >>> I assume by method you are implying methods within the oop class itself? >> Not necessarily. We already have a couple of inline methods is globalDefinitions.hpp. Would that work? > That would work in the case of CAST_TO_OOP, where the type to cast value to is known, an oop. In the case of CAST_FROM_OOP, it wouldn't work as nicely without having to introduce many different inline methods based on the different types that an oop must be cast to. How about a template method? > > Lois >> >>> That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. >>> >>> Thanks for the initial review, >>> Lois >>> >>>> On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: >>>> >>>>> Please review the following fix: >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >>>>> >>>>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >>>>> CheckUnhandledOops has limited usefulness now bug links at: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>>>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>>>> >>>>> Summary of fix: >>>>> >>>>> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >>>>> >>>>> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >>>>> a. Addition of a non-volatile copy constructor to address compile time errors >>>>> reported in JDK-7180556 and also currently by g++ compilers on Linux. >>>>> b. Addition of member wise assignment operators to handle many instances >>>>> of [non]volatile to [non]volatile oops within the JVM. >>>>> Note: Solaris compilers would not allow for the member wise assignment operators >>>>> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >>>>> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >>>>> assignment operator. So the g++ compilers needed these different flavors >>>>> of the assignment operator and Solaris did not. >>>>> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >>>>> g++ specifically complained when trying to pass a volatile "this" pointer. >>>>> e. Removal of the ambiguous behavior of having overloaded copy constructor and >>>>> explicit user conversion member functions defined of both integral and void *. >>>>> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >>>>> >>>>> 2. Change #1e had the consequence of C++ compilers now generating compile time >>>>> errors where the practice has been to cast an oop to and from an integral type such >>>>> as intptr_t. To allow for this practice to continue, when oop is a structure and not >>>>> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >>>>> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >>>>> >>>>> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >>>>> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >>>>> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >>>>> >>>>> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >>>>> cast away the volatileness of the lvalue. There is already precedence for this >>>>> type of change within utilities/taskqueue.hpp. The following comment was in place: >>>>> >>>>> // g++ complains if the volatile result of the assignment is >>>>> // unused, so we cast the volatile away. We cannot cast >>>>> directly >>>>> // to void, because gcc treats that as not using the result >>>>> of the >>>>> // assignment. However, casting to E& means that we trigger an >>>>> // unused-value warning. So, we cast the E& to void. >>>>> >>>>> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >>>>> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >>>>> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >>>>> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >>>>> allowing for all flavors of volatile/non-volatile member wise assignment operators. >>>>> Per Liden of the GC group did pre-review this specific change with regards to performance >>>>> implications and was not concerned. >>>>> >>>>> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >>>>> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >>>>> fastdebug build, an unresolved symbol occurred. >>>>> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >>>>> U Hashtable::_seed >>>>> 0000000000848890 t Hashtable::seed() >>>>> ... >>>>> >>>>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >>>>> >>>>> Builds: >>>>> Solaris (12u1 & 12u3 C++ compilers), >>>>> MacOS (llvm-g++ & clang++ compilers), >>>>> Linux (g++ v4.4.3 & g++ v4.7.3), >>>>> VS2010 >>>>> >>>>> Tests: >>>>> JTREG on MacOS, >>>>> vm.quick.testlist on LInux, >>>>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>>>> JCK vm on Windows >>>>> >>>>> Thank you, Lois >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > From vladimir.kozlov at oracle.com Thu Sep 19 16:51:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Sep 2013 16:51:29 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> Message-ID: <523B8E01.9070809@oracle.com> Good. Vladimir On 9/19/13 4:08 PM, Christian Thalinger wrote: > JPRT found some problems. Apparently something does #define C2 'E' on Solaris so I had to prefix all kind flags with KIND_: > > + // flag kind > + KIND_PRODUCT = 1 << 4, > + KIND_MANAGEABLE = 1 << 5, > + KIND_DIAGNOSTIC = 1 << 6, > + KIND_EXPERIMENTAL = 1 << 7, > + KIND_NOT_PRODUCT = 1 << 8, > + KIND_DEVELOP = 1 << 9, > + KIND_PLATFORM_DEPENDENT = 1 << 10, > + KIND_READ_WRITE = 1 << 11, > + KIND_C1 = 1 << 12, > + KIND_C2 = 1 << 13, > + KIND_ARCH = 1 << 14, > + KIND_SHARK = 1 << 15, > + KIND_LP64_PRODUCT = 1 << 16, > + KIND_COMMERCIAL = 1 << 17, > > Two other problems found by Visual Studio were a bool return: > > + bool Flag::get_bool() const { > + if (is_constant_in_binary()) { > + return _value != 0; > + } else { > + return *((bool*) _addr); > + } > + } > > and the size_t changes at the bottom of this file: > > http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html > > Everything else (except the renames) are the same. I tried to create an incremental webrev but I failed. Sorry. > > On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: > >> >> On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: >> >>> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>>> >>>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>>> >>>>> Christian, >>>>> >>>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>>> >>>> Yes, good point. >>>> >>>>> >>>>> It would be nice enumerate flag's type and use int instead of strings: >>>>> >>>>> enum { >>>>> bool_flag = 1, >>>>> intx_flag = 2, >>>>> >>>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>>> >>>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >>> >>> Do it in separate changes after you push this. >>> And if you remove _type field later you don't need to move _flags now. >>> So you can push your current changes as it is. They are good. >> >> Thank you, Vladimir. -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> -- Chris >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>>> >>>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>>> >>>>>>> + if (is_constant_in_binary()) { >>>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>>> >>>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>>> >>>>>> Good point. I made that change: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>>> >>>>>>> >>>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>>> >>>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>>> >>>>>>> >>>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>>> >>>>>> The 32-bit product build also contains the server compiler. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>>> >>>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>>> >>>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>>> >>>>>>>> Before: >>>>>>>> >>>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>>> Attaching to process 9399, please wait... >>>>>>>> hsdb> flags -nd >>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>> UseCompressedOops = true 5 >>>>>>>> UseParallelGC = true 5 >>>>>>>> hsdb> flags InlineMathNatives >>>>>>>> Couldn't find flag: InlineMathNatives >>>>>>>> >>>>>>>> After: >>>>>>>> >>>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>>> Attaching to process 3726, please wait... >>>>>>>> hsdb> flags -nd >>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>> UseCompressedOops = true 5 >>>>>>>> UseParallelGC = true 5 >>>>>>>> hsdb> flags InlineMathNatives >>>>>>>> InlineMathNatives = true 0 >>>>>>>> >>>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>>> >>>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>>> >>>>>>>> The output for product builds is unchanged. >>>>>>>> >>>>>> >>>> >> > From christian.thalinger at oracle.com Thu Sep 19 18:34:11 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Sep 2013 18:34:11 -0700 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523B9F82.6020107@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> <523B7874.4040605@oracle.com> <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> <523B8729.8090803@oracle.com> <28F5421A-B77B-4675-8A0A-153B0434E71A@oracle.com> <523B9F82.6020107@oracle.com> Message-ID: On Sep 19, 2013, at 6:06 PM, Lois Foltan wrote: > > On 9/19/2013 7:25 PM, Christian Thalinger wrote: >> On Sep 19, 2013, at 4:22 PM, Lois Foltan wrote: >> >>> On 9/19/2013 6:27 PM, Christian Thalinger wrote: >>>> On Sep 19, 2013, at 3:19 PM, Lois Foltan wrote: >>>> >>>>> On 9/19/2013 6:09 PM, Christian Thalinger wrote: >>>>>> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>>>> + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>>>> >>>>>> Could these two macros also be a method? >>>>> Hi Christian, >>>>> I assume by method you are implying methods within the oop class itself? >>>> Not necessarily. We already have a couple of inline methods is globalDefinitions.hpp. Would that work? >>> That would work in the case of CAST_TO_OOP, where the type to cast value to is known, an oop. In the case of CAST_FROM_OOP, it wouldn't work as nicely without having to introduce many different inline methods based on the different types that an oop must be cast to. >> How about a template method? > Hi Christian, > I had to prototype this idea, here's the implementation I came up with > template inline oop cast_to_oop(T value) { > return (oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))value); > } > template inline T cast_from_oop(oop& o) { > return (T)(CHECK_UNHANDLED_OOPS_ONLY((void*))o); > } > The cast_from_oop() template method vs. the CAST_FROM_OOP() macro is a wash, in that no extra copy construction was incurred. The cast_to_oop() template method vs. the CAST_TO_OOP() macro was not. There was one extra call to the (void *) conversion operator and an extra copy construction. I believe this can be attributed to the return of the oop since the temporary oop that was constructed could not be returned by reference since it is a temporary, thus an extra copy construction occurred to return it by value. Given the extra copy construction, it is better to stick with the macros. But this is only when CHECK_UNHANDLED_OOPS is on, right? In a product there can't be a copy construction. If that's the case I'd say we go with the template method because the tiny overhead in a fastdebug build is negligible. > > Thanks, > Lois >> >>> Lois >>>>> That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. >>>>> >>>>> Thanks for the initial review, >>>>> Lois >>>>> >>>>>> On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: >>>>>> >>>>>>> Please review the following fix: >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >>>>>>> >>>>>>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >>>>>>> CheckUnhandledOops has limited usefulness now bug links at: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>>>>>> >>>>>>> Summary of fix: >>>>>>> >>>>>>> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >>>>>>> >>>>>>> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >>>>>>> a. Addition of a non-volatile copy constructor to address compile time errors >>>>>>> reported in JDK-7180556 and also currently by g++ compilers on Linux. >>>>>>> b. Addition of member wise assignment operators to handle many instances >>>>>>> of [non]volatile to [non]volatile oops within the JVM. >>>>>>> Note: Solaris compilers would not allow for the member wise assignment operators >>>>>>> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >>>>>>> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >>>>>>> assignment operator. So the g++ compilers needed these different flavors >>>>>>> of the assignment operator and Solaris did not. >>>>>>> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >>>>>>> g++ specifically complained when trying to pass a volatile "this" pointer. >>>>>>> e. Removal of the ambiguous behavior of having overloaded copy constructor and >>>>>>> explicit user conversion member functions defined of both integral and void *. >>>>>>> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >>>>>>> >>>>>>> 2. Change #1e had the consequence of C++ compilers now generating compile time >>>>>>> errors where the practice has been to cast an oop to and from an integral type such >>>>>>> as intptr_t. To allow for this practice to continue, when oop is a structure and not >>>>>>> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >>>>>>> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >>>>>>> >>>>>>> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >>>>>>> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >>>>>>> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >>>>>>> >>>>>>> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >>>>>>> cast away the volatileness of the lvalue. There is already precedence for this >>>>>>> type of change within utilities/taskqueue.hpp. The following comment was in place: >>>>>>> >>>>>>> // g++ complains if the volatile result of the assignment is >>>>>>> // unused, so we cast the volatile away. We cannot cast >>>>>>> directly >>>>>>> // to void, because gcc treats that as not using the result >>>>>>> of the >>>>>>> // assignment. However, casting to E& means that we trigger an >>>>>>> // unused-value warning. So, we cast the E& to void. >>>>>>> >>>>>>> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >>>>>>> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >>>>>>> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >>>>>>> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >>>>>>> allowing for all flavors of volatile/non-volatile member wise assignment operators. >>>>>>> Per Liden of the GC group did pre-review this specific change with regards to performance >>>>>>> implications and was not concerned. >>>>>>> >>>>>>> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >>>>>>> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >>>>>>> fastdebug build, an unresolved symbol occurred. >>>>>>> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >>>>>>> U Hashtable::_seed >>>>>>> 0000000000848890 t Hashtable::seed() >>>>>>> ... >>>>>>> >>>>>>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >>>>>>> >>>>>>> Builds: >>>>>>> Solaris (12u1 & 12u3 C++ compilers), >>>>>>> MacOS (llvm-g++ & clang++ compilers), >>>>>>> Linux (g++ v4.4.3 & g++ v4.7.3), >>>>>>> VS2010 >>>>>>> >>>>>>> Tests: >>>>>>> JTREG on MacOS, >>>>>>> vm.quick.testlist on LInux, >>>>>>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>>>>>> JCK vm on Windows >>>>>>> >>>>>>> Thank you, Lois >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > From christian.thalinger at oracle.com Thu Sep 19 18:34:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Sep 2013 18:34:25 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <523B8E01.9070809@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> <523B8E01.9070809@oracle.com> Message-ID: Thank you, again, Vladimir. On Sep 19, 2013, at 4:51 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 9/19/13 4:08 PM, Christian Thalinger wrote: >> JPRT found some problems. Apparently something does #define C2 'E' on Solaris so I had to prefix all kind flags with KIND_: >> >> + // flag kind >> + KIND_PRODUCT = 1 << 4, >> + KIND_MANAGEABLE = 1 << 5, >> + KIND_DIAGNOSTIC = 1 << 6, >> + KIND_EXPERIMENTAL = 1 << 7, >> + KIND_NOT_PRODUCT = 1 << 8, >> + KIND_DEVELOP = 1 << 9, >> + KIND_PLATFORM_DEPENDENT = 1 << 10, >> + KIND_READ_WRITE = 1 << 11, >> + KIND_C1 = 1 << 12, >> + KIND_C2 = 1 << 13, >> + KIND_ARCH = 1 << 14, >> + KIND_SHARK = 1 << 15, >> + KIND_LP64_PRODUCT = 1 << 16, >> + KIND_COMMERCIAL = 1 << 17, >> >> Two other problems found by Visual Studio were a bool return: >> >> + bool Flag::get_bool() const { >> + if (is_constant_in_binary()) { >> + return _value != 0; >> + } else { >> + return *((bool*) _addr); >> + } >> + } >> >> and the size_t changes at the bottom of this file: >> >> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >> >> Everything else (except the renames) are the same. I tried to create an incremental webrev but I failed. Sorry. >> >> On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: >> >>> >>> On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: >>> >>>> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>>>> >>>>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Christian, >>>>>> >>>>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>>>> >>>>> Yes, good point. >>>>> >>>>>> >>>>>> It would be nice enumerate flag's type and use int instead of strings: >>>>>> >>>>>> enum { >>>>>> bool_flag = 1, >>>>>> intx_flag = 2, >>>>>> >>>>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>>>> >>>>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >>>> >>>> Do it in separate changes after you push this. >>>> And if you remove _type field later you don't need to move _flags now. >>>> So you can push your current changes as it is. They are good. >>> >>> Thank you, Vladimir. -- Chris >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>>>> >>>>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>>>> >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>>>> >>>>>>>> + if (is_constant_in_binary()) { >>>>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>>>> >>>>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>>>> >>>>>>> Good point. I made that change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>>>> >>>>>>>> >>>>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>>>> >>>>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>>>> >>>>>>>> >>>>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>>>> >>>>>>> The 32-bit product build also contains the server compiler. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>>>> >>>>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>>>> >>>>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>>>> >>>>>>>>> Before: >>>>>>>>> >>>>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>>>> Attaching to process 9399, please wait... >>>>>>>>> hsdb> flags -nd >>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>> UseCompressedOops = true 5 >>>>>>>>> UseParallelGC = true 5 >>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>> Couldn't find flag: InlineMathNatives >>>>>>>>> >>>>>>>>> After: >>>>>>>>> >>>>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>>>> Attaching to process 3726, please wait... >>>>>>>>> hsdb> flags -nd >>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>> UseCompressedOops = true 5 >>>>>>>>> UseParallelGC = true 5 >>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>> InlineMathNatives = true 0 >>>>>>>>> >>>>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>>>> >>>>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>>>> >>>>>>>>> The output for product builds is unchanged. >>>>>>>>> >>>>>>> >>>>> >>> >> From coleen.phillimore at oracle.com Thu Sep 19 19:14:05 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 19 Sep 2013 22:14:05 -0400 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523B5522.8020207@oracle.com> References: <523B5522.8020207@oracle.com> Message-ID: <523BAF6D.70207@oracle.com> Stefan, Thanks for sending this to hotspot-dev. This change seems okay but the original intent was that the free chunks went along with their virtual space list, which manage the list of mmap spaces. So that's why they were contained by VirtualSpaceList. And ChunkManager was more hidden - nobody was supposed to know about it. Now all the SpaceManagers have an extra pointer, and there are two space managers per class loader in the case of compressed class pointers, so that could add up to an interesting amount of extra memory, especially for 2M anonymous classes. Since SpaceManager has a back pointer to VirtualSpaceList, you could still have ChunkManager belong to VSL and indirectly get them: SpaceManager::chunk_manager() { return _vs_list->chunk_manager(); } Of if you don't like that, you could have: SpaceManager::chunk_manager() { return *_mdtype == Metaspace::ClassType ? _chunk_manager_class : the other one; } *The C heap allocation looks a lot cleaner, and the change to get_new_chunk, which is the main purpose of this change looks really good. I'm just worried about the extra footprint and there is already _vs_list. Maybe neither is needed and could be fetched by _mdtype, which wasn't there when _vs_list was added. Can you adjust your change to not add this memory? Or file a new bug to remove the additional footprint after this? Thanks, Coleen On 9/19/2013 3:48 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8025096 > > In the fix for 'JDK-8024547 > : MaxMetaspaceSize > should limit the committed memory used by the metaspaces' we need to > make a clearer distinction between when new memory is committed and > when memory is allocated inside already committed memory. > > Moving the ChunkManager, which handles the free chunk list, out of the > VirtualSpaceList, which handles the committed metaspace memory, is a > step in that direction. > > Changes: > - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. > - Move the inc_container_count() into ChunkManager::free_chunks_get. > Now the Chunk manager calls dec_container_count when chunks are > inserted in the chunk free list and inc_container_count when chunks > are removed from the chunk free list. > - Moved the ChunkManager::chunk_freelist_allocate() call out from the > VirtualSpaceList::get_new_chunk() > > thanks, > StefanK From stefan.karlsson at oracle.com Thu Sep 19 23:09:37 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 08:09:37 +0200 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523BAF6D.70207@oracle.com> References: <523B5522.8020207@oracle.com> <523BAF6D.70207@oracle.com> Message-ID: <523BE6A1.1070903@oracle.com> On 9/20/13 4:14 AM, Coleen Phillmore wrote: > > Stefan, > > Thanks for sending this to hotspot-dev. This change seems okay but > the original intent was that the free chunks went along with their > virtual space list, which manage the list of mmap spaces. So that's > why they were contained by VirtualSpaceList. And ChunkManager was > more hidden - nobody was supposed to know about it. But that's not what the code looked like. All over the place you called vs_list()->chunk_manager()->... On only a few places where ChunkManager really used directly by the VirtualSpaceList. > > Now all the SpaceManagers have an extra pointer, and there are two > space managers per class loader in the case of compressed class > pointers, so that could add up to an interesting amount of extra > memory, especially for 2M anonymous classes. I see your point. But if that memory wastage is that important, then I don't understand why the SpaceManager has a VirtualSpaceList* _vs_list field, when the correct VSL can be fetched globally as you suggest below that I do with SpaceManager::chunk_manager(). There are even more space savings to be made in the SpaceManager class. The _medium_chunk_bunch isn't used at all, for example. > > Since SpaceManager has a back pointer to VirtualSpaceList, you could > still have ChunkManager belong to VSL and indirectly get them: > SpaceManager::chunk_manager() { return _vs_list->chunk_manager(); } > > Of if you don't like that, you could have: > > SpaceManager::chunk_manager() { return *_mdtype == > Metaspace::ClassType ? _chunk_manager_class : the other one; } Sure. I can do that, but then I would like to do the same for the VirtualSpaceList* _vs_list. > > *The C heap allocation looks a lot cleaner, and the change to > get_new_chunk, which is the main purpose of this change looks really > good. I'm just worried about the extra footprint and there is > already _vs_list. Maybe neither is needed and could be fetched by > _mdtype, which wasn't there when _vs_list was added. Yes. > Can you adjust your change to not add this memory? Or file a new bug > to remove the additional footprint after this? I'll move out _chunk_manager and _vs_list from SpaceManager, and send out a new review request later today. thanks for your input, StefanK > > Thanks, > Coleen > > On 9/19/2013 3:48 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025096 >> >> In the fix for 'JDK-8024547 >> : MaxMetaspaceSize >> should limit the committed memory used by the metaspaces' we need to >> make a clearer distinction between when new memory is committed and >> when memory is allocated inside already committed memory. >> >> Moving the ChunkManager, which handles the free chunk list, out of >> the VirtualSpaceList, which handles the committed metaspace memory, >> is a step in that direction. >> >> Changes: >> - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. >> - Move the inc_container_count() into ChunkManager::free_chunks_get. >> Now the Chunk manager calls dec_container_count when chunks are >> inserted in the chunk free list and inc_container_count when chunks >> are removed from the chunk free list. >> - Moved the ChunkManager::chunk_freelist_allocate() call out from the >> VirtualSpaceList::get_new_chunk() >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Thu Sep 19 23:54:13 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 08:54:13 +0200 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523B5522.8020207@oracle.com> References: <523B5522.8020207@oracle.com> Message-ID: <523BF115.9050702@oracle.com> http://cr.openjdk.java.net/~stefank/8025096/webrev.01/ New webrev based on Coleen's comments. Changes: - Moved the _vs_list pointer out from SpaceManager - Removed the unused _medium_chunk_bunch field. thanks, StefanK On 9/19/13 9:48 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8025096 > > In the fix for 'JDK-8024547 > : MaxMetaspaceSize > should limit the committed memory used by the metaspaces' we need to > make a clearer distinction between when new memory is committed and > when memory is allocated inside already committed memory. > > Moving the ChunkManager, which handles the free chunk list, out of the > VirtualSpaceList, which handles the committed metaspace memory, is a > step in that direction. > > Changes: > - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. > - Move the inc_container_count() into ChunkManager::free_chunks_get. > Now the Chunk manager calls dec_container_count when chunks are > inserted in the chunk free list and inc_container_count when chunks > are removed from the chunk free list. > - Moved the ChunkManager::chunk_freelist_allocate() call out from the > VirtualSpaceList::get_new_chunk() > > thanks, > StefanK From mikael.gerdin at oracle.com Fri Sep 20 00:29:15 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 20 Sep 2013 09:29:15 +0200 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523BF115.9050702@oracle.com> References: <523B5522.8020207@oracle.com> <523BF115.9050702@oracle.com> Message-ID: <523BF94B.60601@oracle.com> Stefan, On 2013-09-20 08:54, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025096/webrev.01/ > > New webrev based on Coleen's comments. > > Changes: > - Moved the _vs_list pointer out from SpaceManager > - Removed the unused _medium_chunk_bunch field. I think the moving of ChunkManager makes sense, the change looks good. Thanks for getting this patch ready so soon! /Mikael > > thanks, > StefanK > > On 9/19/13 9:48 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025096 >> >> In the fix for 'JDK-8024547 >> : MaxMetaspaceSize >> should limit the committed memory used by the metaspaces' we need to >> make a clearer distinction between when new memory is committed and >> when memory is allocated inside already committed memory. >> >> Moving the ChunkManager, which handles the free chunk list, out of the >> VirtualSpaceList, which handles the committed metaspace memory, is a >> step in that direction. >> >> Changes: >> - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. >> - Move the inc_container_count() into ChunkManager::free_chunks_get. >> Now the Chunk manager calls dec_container_count when chunks are >> inserted in the chunk free list and inc_container_count when chunks >> are removed from the chunk free list. >> - Moved the ChunkManager::chunk_freelist_allocate() call out from the >> VirtualSpaceList::get_new_chunk() >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Fri Sep 20 00:49:05 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 09:49:05 +0200 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523BF94B.60601@oracle.com> References: <523B5522.8020207@oracle.com> <523BF115.9050702@oracle.com> <523BF94B.60601@oracle.com> Message-ID: <523BFDF1.1030909@oracle.com> On 09/20/2013 09:29 AM, Mikael Gerdin wrote: > Stefan, > > On 2013-09-20 08:54, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025096/webrev.01/ >> >> New webrev based on Coleen's comments. >> >> Changes: >> - Moved the _vs_list pointer out from SpaceManager >> - Removed the unused _medium_chunk_bunch field. > > I think the moving of ChunkManager makes sense, the change looks good. > Thanks for getting this patch ready so soon! Thanks, Mikael. StefanK > > /Mikael > >> >> thanks, >> StefanK >> >> On 9/19/13 9:48 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025096 >>> >>> In the fix for 'JDK-8024547 >>> : MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces' we need to >>> make a clearer distinction between when new memory is committed and >>> when memory is allocated inside already committed memory. >>> >>> Moving the ChunkManager, which handles the free chunk list, out of the >>> VirtualSpaceList, which handles the committed metaspace memory, is a >>> step in that direction. >>> >>> Changes: >>> - Move the ChunkManager instances from VirtualSpaceList to >>> SpaceManager. >>> - Move the inc_container_count() into ChunkManager::free_chunks_get. >>> Now the Chunk manager calls dec_container_count when chunks are >>> inserted in the chunk free list and inc_container_count when chunks >>> are removed from the chunk free list. >>> - Moved the ChunkManager::chunk_freelist_allocate() call out from the >>> VirtualSpaceList::get_new_chunk() >>> >>> thanks, >>> StefanK >> From dan at danny.cz Fri Sep 20 01:34:36 2013 From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=) Date: Fri, 20 Sep 2013 10:34:36 +0200 Subject: PATCH: swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp In-Reply-To: <523A7A1A.1060208@oracle.com> References: <20130916120950.2005303d0df54386b7c634a1@danny.cz> <1379406430.2702.19.camel@cirrus> <52382564.3060709@oracle.com> <1379414362.2702.39.camel@cirrus> <20130917141709.4fd55e2cc324bea1eaf7fd99@danny.cz> <52384FAE.5000301@oracle.com> <20130917155317.0b0e617f9148afff2b4f7646@danny.cz> <523A7A1A.1060208@oracle.com> Message-ID: <20130920103436.15837bf71efba29090b1ea91@danny.cz> On Thu, 19 Sep 2013 14:14:18 +1000 David Holmes wrote: > On 17/09/2013 11:53 PM, Dan Hor?k wrote: > > On Tue, 17 Sep 2013 22:48:46 +1000 > > David Holmes wrote: > > > >> Hi Dan, > >> > >> On 17/09/2013 10:17 PM, Dan Hor?k wrote: > >>> On Tue, 17 Sep 2013 12:39:22 +0200 > >>> Thomas Schatzl wrote: > >>> > >>>> Hi Bengt, > >>>> > >>>> On Tue, 2013-09-17 at 11:48 +0200, Bengt Rutisson wrote: > >>>>> Hello Dan and Thomas, > >>>>> > >>>>> The change looks good to me to. Thanks for finding and fixing > >>>>> this! > >>>>> > >>>> > >>>> Thanks for the quick review. > >>>> > >>>> @Dan: The patch is now in the push queue and will go through the > >>>> hotspot-gc mercurial tree. > >>> > >>> thank you guys, any action still needed from me? > >>> > >>> There are other places in the hotspot code where int and size_t > >>> types are mixed (eg. in MAX2()/MIN2()) causing compile failures, > >>> so I'll submit another patch for these issues. > >> > >> Have you actually eradicated all compile-time errors due to this > >> issue? I worry that things will just unwravel as you try to do > >> this. > > > > Some time ago the patch at [1] fixed all those conflicts and we > > similar patch for openjdk7 in Fedora. But I guess it will need an > > update for the recent sources. > > > > [1] > > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk-size_t.patch > > Shouldn't the integer promotion rules handle this without needing > casts? I'm not clearly seeing the problem here. IIRC the MIN2() and MAX2() are implemented as templates with base integer types and this makes the problem when "size_t" (aka unsigned long) and "unsigned int" go in as parameters Dan From stefan.karlsson at oracle.com Fri Sep 20 04:35:58 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 13:35:58 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523B1143.8080602@oracle.com> References: <523B1143.8080602@oracle.com> Message-ID: <523C331E.1080207@oracle.com> The webrev I sent out contained a bug, that had been fixed in a later patch. I've incorporated that fix and reran the tests. Please, refresh you browser cache and re-review this patch. thanks, StefanK On 09/19/2013 04:59 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8025059 > > The following code in Metaspace::should_expand: > > if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { > size_t real_allocated = Metaspace::space_list()->reserved_words() + > MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); > if (real_allocated >= MaxMetaspaceSize) { > return false; > } > > doesn't convert Metaspace::space_list()->reserved_words() to bytes, as > it should. > > Note that when JDK-8024547 gets fixed, this check will be rewritten to > limit the amount of committed memory in both the Class and NonClass > metaspaces. See: > https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize > should limit the committed memory used by the metaspaces > > Testing: I've run our internal testing that sets the MaxMetaspaceSize. > > thanks, > StefanK From mikael.gerdin at oracle.com Fri Sep 20 04:51:57 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 20 Sep 2013 13:51:57 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523C331E.1080207@oracle.com> References: <523B1143.8080602@oracle.com> <523C331E.1080207@oracle.com> Message-ID: <523C36DD.1070606@oracle.com> Stefan, On 09/20/2013 01:35 PM, Stefan Karlsson wrote: > The webrev I sent out contained a bug, that had been fixed in a later > patch. I've incorporated that fix and reran the tests. > > Please, refresh you browser cache and re-review this patch. The change looks good to me. /Mikael > > thanks, > StefanK > > On 09/19/2013 04:59 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025059 >> >> The following code in Metaspace::should_expand: >> >> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >> size_t real_allocated = Metaspace::space_list()->reserved_words() + >> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >> if (real_allocated >= MaxMetaspaceSize) { >> return false; >> } >> >> doesn't convert Metaspace::space_list()->reserved_words() to bytes, as >> it should. >> >> Note that when JDK-8024547 gets fixed, this check will be rewritten to >> limit the amount of committed memory in both the Class and NonClass >> metaspaces. See: >> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >> should limit the committed memory used by the metaspaces >> >> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >> >> thanks, >> StefanK > From coleen.phillimore at oracle.com Fri Sep 20 04:54:55 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 20 Sep 2013 07:54:55 -0400 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523BE6A1.1070903@oracle.com> References: <523B5522.8020207@oracle.com> <523BAF6D.70207@oracle.com> <523BE6A1.1070903@oracle.com> Message-ID: <523C378F.1050504@oracle.com> Thanks, Stefan. On 9/20/2013 2:09 AM, Stefan Karlsson wrote: > On 9/20/13 4:14 AM, Coleen Phillmore wrote: >> >> Stefan, >> >> Thanks for sending this to hotspot-dev. This change seems okay but >> the original intent was that the free chunks went along with their >> virtual space list, which manage the list of mmap spaces. So that's >> why they were contained by VirtualSpaceList. And ChunkManager was >> more hidden - nobody was supposed to know about it. > > But that's not what the code looked like. All over the place you > called vs_list()->chunk_manager()->... On only a few places where > ChunkManager really used directly by the VirtualSpaceList. > >> >> Now all the SpaceManagers have an extra pointer, and there are two >> space managers per class loader in the case of compressed class >> pointers, so that could add up to an interesting amount of extra >> memory, especially for 2M anonymous classes. > > I see your point. But if that memory wastage is that important, then I > don't understand why the SpaceManager has a VirtualSpaceList* _vs_list > field, when the correct VSL can be fetched globally as you suggest > below that I do with SpaceManager::chunk_manager(). See below. The _mdtype field is new. > > There are even more space savings to be made in the SpaceManager > class. The _medium_chunk_bunch isn't used at all, for example. Great. We can remove that too with a different edit. > >> >> Since SpaceManager has a back pointer to VirtualSpaceList, you could >> still have ChunkManager belong to VSL and indirectly get them: >> SpaceManager::chunk_manager() { return _vs_list->chunk_manager(); } >> >> Of if you don't like that, you could have: >> >> SpaceManager::chunk_manager() { return *_mdtype == >> Metaspace::ClassType ? _chunk_manager_class : the other one; } > > Sure. I can do that, but then I would like to do the same for the > VirtualSpaceList* _vs_list. > >> >> *The C heap allocation looks a lot cleaner, and the change to >> get_new_chunk, which is the main purpose of this change looks really >> good. I'm just worried about the extra footprint and there is >> already _vs_list. Maybe neither is needed and could be fetched by >> _mdtype, which wasn't there when _vs_list was added. > > Yes. > >> Can you adjust your change to not add this memory? Or file a new >> bug to remove the additional footprint after this? > > I'll move out _chunk_manager and _vs_list from SpaceManager, and send > out a new review request later today. Thanks!! Coleen > > thanks for your input, > StefanK >> >> Thanks, >> Coleen >> >> On 9/19/2013 3:48 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025096 >>> >>> In the fix for 'JDK-8024547 >>> : MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces' we need to >>> make a clearer distinction between when new memory is committed and >>> when memory is allocated inside already committed memory. >>> >>> Moving the ChunkManager, which handles the free chunk list, out of >>> the VirtualSpaceList, which handles the committed metaspace memory, >>> is a step in that direction. >>> >>> Changes: >>> - Move the ChunkManager instances from VirtualSpaceList to >>> SpaceManager. >>> - Move the inc_container_count() into ChunkManager::free_chunks_get. >>> Now the Chunk manager calls dec_container_count when chunks are >>> inserted in the chunk free list and inc_container_count when chunks >>> are removed from the chunk free list. >>> - Moved the ChunkManager::chunk_freelist_allocate() call out from >>> the VirtualSpaceList::get_new_chunk() >>> >>> thanks, >>> StefanK >> > From coleen.phillimore at oracle.com Fri Sep 20 05:04:33 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 20 Sep 2013 08:04:33 -0400 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523BF115.9050702@oracle.com> References: <523B5522.8020207@oracle.com> <523BF115.9050702@oracle.com> Message-ID: <523C39D1.6070304@oracle.com> This looks great. Coleen On 9/20/2013 2:54 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025096/webrev.01/ > > New webrev based on Coleen's comments. > > Changes: > - Moved the _vs_list pointer out from SpaceManager > - Removed the unused _medium_chunk_bunch field. > > thanks, > StefanK > > On 9/19/13 9:48 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025096 >> >> In the fix for 'JDK-8024547 >> : MaxMetaspaceSize >> should limit the committed memory used by the metaspaces' we need to >> make a clearer distinction between when new memory is committed and >> when memory is allocated inside already committed memory. >> >> Moving the ChunkManager, which handles the free chunk list, out of >> the VirtualSpaceList, which handles the committed metaspace memory, >> is a step in that direction. >> >> Changes: >> - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. >> - Move the inc_container_count() into ChunkManager::free_chunks_get. >> Now the Chunk manager calls dec_container_count when chunks are >> inserted in the chunk free list and inc_container_count when chunks >> are removed from the chunk free list. >> - Moved the ChunkManager::chunk_freelist_allocate() call out from the >> VirtualSpaceList::get_new_chunk() >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Fri Sep 20 05:11:21 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 14:11:21 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523C36DD.1070606@oracle.com> References: <523B1143.8080602@oracle.com> <523C331E.1080207@oracle.com> <523C36DD.1070606@oracle.com> Message-ID: <523C3B69.3080404@oracle.com> On 09/20/2013 01:51 PM, Mikael Gerdin wrote: > Stefan, > > On 09/20/2013 01:35 PM, Stefan Karlsson wrote: >> The webrev I sent out contained a bug, that had been fixed in a later >> patch. I've incorporated that fix and reran the tests. >> >> Please, refresh you browser cache and re-review this patch. > > The change looks good to me. Thanks, Mikael. StefanK > > /Mikael > >> >> thanks, >> StefanK >> >> On 09/19/2013 04:59 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>> >>> The following code in Metaspace::should_expand: >>> >>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> if (real_allocated >= MaxMetaspaceSize) { >>> return false; >>> } >>> >>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, as >>> it should. >>> >>> Note that when JDK-8024547 gets fixed, this check will be rewritten to >>> limit the amount of committed memory in both the Class and NonClass >>> metaspaces. See: >>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces >>> >>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Fri Sep 20 05:14:08 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 14:14:08 +0200 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523C39D1.6070304@oracle.com> References: <523B5522.8020207@oracle.com> <523BF115.9050702@oracle.com> <523C39D1.6070304@oracle.com> Message-ID: <523C3C10.4060105@oracle.com> On 09/20/2013 02:04 PM, Coleen Phillmore wrote: > > This looks great. Thanks, Coleen. StefanK > Coleen > > On 9/20/2013 2:54 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025096/webrev.01/ >> >> New webrev based on Coleen's comments. >> >> Changes: >> - Moved the _vs_list pointer out from SpaceManager >> - Removed the unused _medium_chunk_bunch field. >> >> thanks, >> StefanK >> >> On 9/19/13 9:48 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025096 >>> >>> In the fix for 'JDK-8024547 >>> : MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces' we need to >>> make a clearer distinction between when new memory is committed and >>> when memory is allocated inside already committed memory. >>> >>> Moving the ChunkManager, which handles the free chunk list, out of >>> the VirtualSpaceList, which handles the committed metaspace memory, >>> is a step in that direction. >>> >>> Changes: >>> - Move the ChunkManager instances from VirtualSpaceList to >>> SpaceManager. >>> - Move the inc_container_count() into ChunkManager::free_chunks_get. >>> Now the Chunk manager calls dec_container_count when chunks are >>> inserted in the chunk free list and inc_container_count when chunks >>> are removed from the chunk free list. >>> - Moved the ChunkManager::chunk_freelist_allocate() call out from >>> the VirtualSpaceList::get_new_chunk() >>> >>> thanks, >>> StefanK >> > From coleen.phillimore at oracle.com Fri Sep 20 05:10:46 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 20 Sep 2013 08:10:46 -0400 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523C36DD.1070606@oracle.com> References: <523B1143.8080602@oracle.com> <523C331E.1080207@oracle.com> <523C36DD.1070606@oracle.com> Message-ID: <523C3B46.7080002@oracle.com> This is good. Coleen On 9/20/2013 7:51 AM, Mikael Gerdin wrote: > Stefan, > > On 09/20/2013 01:35 PM, Stefan Karlsson wrote: >> The webrev I sent out contained a bug, that had been fixed in a later >> patch. I've incorporated that fix and reran the tests. >> >> Please, refresh you browser cache and re-review this patch. > > The change looks good to me. > > /Mikael > >> >> thanks, >> StefanK >> >> On 09/19/2013 04:59 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>> >>> The following code in Metaspace::should_expand: >>> >>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> if (real_allocated >= MaxMetaspaceSize) { >>> return false; >>> } >>> >>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, as >>> it should. >>> >>> Note that when JDK-8024547 gets fixed, this check will be rewritten to >>> limit the amount of committed memory in both the Class and NonClass >>> metaspaces. See: >>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces >>> >>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>> >>> thanks, >>> StefanK >> > From bengt.rutisson at oracle.com Fri Sep 20 05:13:13 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 20 Sep 2013 14:13:13 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523C331E.1080207@oracle.com> References: <523B1143.8080602@oracle.com> <523C331E.1080207@oracle.com> Message-ID: <523C3BD9.2050408@oracle.com> Looks good. Embarrassing that I didn't catch that the first time around. ;) Bengt On 9/20/13 1:35 PM, Stefan Karlsson wrote: > The webrev I sent out contained a bug, that had been fixed in a later > patch. I've incorporated that fix and reran the tests. > > Please, refresh you browser cache and re-review this patch. > > thanks, > StefanK > > On 09/19/2013 04:59 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025059 >> >> The following code in Metaspace::should_expand: >> >> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >> size_t real_allocated = Metaspace::space_list()->reserved_words() + >> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >> if (real_allocated >= MaxMetaspaceSize) { >> return false; >> } >> >> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >> as it should. >> >> Note that when JDK-8024547 gets fixed, this check will be rewritten >> to limit the amount of committed memory in both the Class and >> NonClass metaspaces. See: >> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >> should limit the committed memory used by the metaspaces >> >> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Fri Sep 20 05:18:26 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 14:18:26 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523C3BD9.2050408@oracle.com> References: <523B1143.8080602@oracle.com> <523C331E.1080207@oracle.com> <523C3BD9.2050408@oracle.com> Message-ID: <523C3D12.5080900@oracle.com> On 09/20/2013 02:13 PM, Bengt Rutisson wrote: > > Looks good. > > Embarrassing that I didn't catch that the first time around. ;) Thanks, Bengt. ;) StefanK > > Bengt > > On 9/20/13 1:35 PM, Stefan Karlsson wrote: >> The webrev I sent out contained a bug, that had been fixed in a later >> patch. I've incorporated that fix and reran the tests. >> >> Please, refresh you browser cache and re-review this patch. >> >> thanks, >> StefanK >> >> On 09/19/2013 04:59 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>> >>> The following code in Metaspace::should_expand: >>> >>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>> if (real_allocated >= MaxMetaspaceSize) { >>> return false; >>> } >>> >>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, >>> as it should. >>> >>> Note that when JDK-8024547 gets fixed, this check will be rewritten >>> to limit the amount of committed memory in both the Class and >>> NonClass metaspaces. See: >>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>> should limit the committed memory used by the metaspaces >>> >>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Fri Sep 20 05:46:44 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 14:46:44 +0200 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523B14AC.5040509@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> Message-ID: <523C43B4.1050105@oracle.com> On 09/19/2013 05:13 PM, Lois Foltan wrote: > > > Please review the following fix: > Webrev: > http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ The changes looks good. There are some changes that I don't fully agree with, but I will not block the push because of them. I'm just going to mention them here for the record: 1) I would personally prefer not to have the CAST_TO_OOP/CAST_FROM_OOP macros and instead explicitly add (void *) casts. 2) I don't understand the need make the code harder to read by adding a SOLAR_ONLY((void*)) instead of just a plain (void*). I'm looking forward to be able to use this feature on Linux! thanks, StefanK > > Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing > const volatile oop& requires ... & > CheckUnhandledOops has limited usefulness now bug links at: > > https://bugs.openjdk.java.net/browse/JDK-7180556 > https://bugs.openjdk.java.net/browse/JDK-7195622 > > Summary of fix: > > Update the C++ oop structure definition in oopsHierarchy.hpp to solve > several problems with the current definition when compiled with > various C++ compilers across supported platforms. These changes > initially address the problem reported in JDK-7180556 and continue > with additional improvements to allow CHECK_UNHANDLED_OOPS to be > defined in all fastdebug builds on all platforms as suggested in > JDK-7195622. Several notes concerning this fix: > > 1. A review should start at understanding the changes made > to oopsHierarchy.hpp > a. Addition of a non-volatile copy constructor to > address compile time errors > reported in JDK-7180556 and also currently by > g++ compilers on Linux. > b. Addition of member wise assignment operators > to handle many instances > of [non]volatile to [non]volatile oops within > the JVM. > Note: Solaris compilers would not allow for > the member wise assignment operators > of every flavor of non-volatile to > volatile and vice versa. However, unlike g++ compilers, > Solaris compilers had no issue > passing a volatile "this" pointer to a non-volatile > assignment operator. So the g++ > compilers needed these different flavors > of the assignment operator and > Solaris did not. > d. For similar reasons as 1b, addition of a > volatile explicit conversion from oop -> void *. > g++ specifically complained when trying to > pass a volatile "this" pointer. > e. Removal of the ambiguous behavior of having > overloaded copy constructor and > explicit user conversion member functions > defined of both integral and void *. > All C++ compilers, except Solaris, issue a > compile time error concerning this ambiguity. > > 2. Change #1e had the consequence of C++ compilers now > generating compile time > errors where the practice has been to cast an oop to > and from an integral type such > as intptr_t. To allow for this practice to continue, > when oop is a structure and not > a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS > is defined, two new > macros were introduced within globalDefinitions.hpp, > CAST_TO_OOP and CAST_FROM_OOP. > > 3. Due to the change in #1a & #1b, the oop structure in no > longer considered a POD (plain old data) > by the g++ compilers on Linux and MacOS. This caused > several changes to be needed > throughout the JVM to add an (void *) cast of an oop > when invoking print_cr(). > > 4. Many instances of an assignment to a volatile oop > required a "const_cast" to > cast away the volatileness of the lvalue. There is > already precedence for this > type of change within utilities/taskqueue.hpp. The > following comment was in place: > > // g++ complains if the volatile result of the assignment is > // unused, so we cast the volatile away. We cannot cast > directly > // to void, because gcc treats that as not using the result > of the > // assignment. However, casting to E& means that we > trigger an > // unused-value warning. So, we cast the E& to void. > > 5. The addition of the volatile keyword to the > GenericTaskQueue's pop_local() & pop_global() > member functions was to accommodate the Solaris C++ > compiler's complaint about the assignment > of the volatile elements of the private member data > _elems when GenericTaskQueue is instantiated > with a non-volatile oop. Line #723 in pop_local(). > This was a result of #1b, Solaris' lack of > allowing for all flavors of volatile/non-volatile > member wise assignment operators. > Per Liden of the GC group did pre-review this specific > change with regards to performance > implications and was not concerned. > > 6. In utilities/hashtable.cpp, required > CHECK_UNHANDLED_OOPS conditional for the instantiation > of "template class Hashtable". With > CHECK_UHANDLED_OOPS specified for a > fastdebug build, an unresolved symbol occurred. > philli:% nm --demangle > build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | > grep seed > U Hashtable short)2304>::_seed > 0000000000848890 t Hashtable short)256>::seed() > ... > > Making these improvements allows for CHECK_UNHANDLED_OOPS to be > defined in all fastdebug builds across the supported platforms. > > Builds: > Solaris (12u1 & 12u3 C++ compilers), > MacOS (llvm-g++ & clang++ compilers), > Linux (g++ v4.4.3 & g++ v4.7.3), > VS2010 > > Tests: > JTREG on MacOS, > vm.quick.testlist on LInux, > nsk.regression.testlist, nsk.stress.testlist on LInux, > JCK vm on Windows > > Thank you, Lois > > > > > > > > > > From stefan.karlsson at oracle.com Fri Sep 20 05:47:25 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 14:47:25 +0200 Subject: Review request: 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize In-Reply-To: <523C3B46.7080002@oracle.com> References: <523B1143.8080602@oracle.com> <523C331E.1080207@oracle.com> <523C36DD.1070606@oracle.com> <523C3B46.7080002@oracle.com> Message-ID: <523C43DD.7030304@oracle.com> On 09/20/2013 02:10 PM, Coleen Phillmore wrote: > > This is good. Thanks, Coleen. StefanK > Coleen > > On 9/20/2013 7:51 AM, Mikael Gerdin wrote: >> Stefan, >> >> On 09/20/2013 01:35 PM, Stefan Karlsson wrote: >>> The webrev I sent out contained a bug, that had been fixed in a later >>> patch. I've incorporated that fix and reran the tests. >>> >>> Please, refresh you browser cache and re-review this patch. >> >> The change looks good to me. >> >> /Mikael >> >>> >>> thanks, >>> StefanK >>> >>> On 09/19/2013 04:59 PM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8025059/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8025059 >>>> >>>> The following code in Metaspace::should_expand: >>>> >>>> if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)) { >>>> size_t real_allocated = Metaspace::space_list()->reserved_words() + >>>> MetaspaceAux::allocated_capacity_bytes(Metaspace::ClassType); >>>> if (real_allocated >= MaxMetaspaceSize) { >>>> return false; >>>> } >>>> >>>> doesn't convert Metaspace::space_list()->reserved_words() to bytes, as >>>> it should. >>>> >>>> Note that when JDK-8024547 gets fixed, this check will be rewritten to >>>> limit the amount of committed memory in both the Class and NonClass >>>> metaspaces. See: >>>> https://bugs.openjdk.java.net/browse/JDK-8024547: MaxMetaspaceSize >>>> should limit the committed memory used by the metaspaces >>>> >>>> Testing: I've run our internal testing that sets the MaxMetaspaceSize. >>>> >>>> thanks, >>>> StefanK >>> >> > From stefan.karlsson at oracle.com Fri Sep 20 06:16:07 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Sep 2013 15:16:07 +0200 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523C43B4.1050105@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <523C43B4.1050105@oracle.com> Message-ID: <523C4A97.7070004@oracle.com> On 09/20/2013 02:46 PM, Stefan Karlsson wrote: > On 09/19/2013 05:13 PM, Lois Foltan wrote: >> >> >> Please review the following fix: >> Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ > > The changes looks good. I forgot this rather benign bug: http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/src/share/vm/oops/klass.inline.hpp.patch inline bool check_klass_alignment(Klass* obj) { - return (intptr_t)obj % KlassAlignmentInBytes == 0; + return CAST_FROM_OOP(intptr_t, obj) % KlassAlignmentInBytes == 0; } obj is not an oop. thanks, StefanK > > There are some changes that I don't fully agree with, but I will not > block the push because of them. I'm just going to mention them here > for the record: > > 1) I would personally prefer not to have the CAST_TO_OOP/CAST_FROM_OOP > macros and instead explicitly add (void *) casts. > > 2) I don't understand the need make the code harder to read by adding > a SOLAR_ONLY((void*)) instead of just a plain (void*). > > I'm looking forward to be able to use this feature on Linux! > > thanks, > StefanK > >> >> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing >> const volatile oop& requires ... & >> CheckUnhandledOops has limited usefulness now bug links at: >> >> https://bugs.openjdk.java.net/browse/JDK-7180556 >> https://bugs.openjdk.java.net/browse/JDK-7195622 >> >> Summary of fix: >> >> Update the C++ oop structure definition in oopsHierarchy.hpp to solve >> several problems with the current definition when compiled with >> various C++ compilers across supported platforms. These changes >> initially address the problem reported in JDK-7180556 and continue >> with additional improvements to allow CHECK_UNHANDLED_OOPS to be >> defined in all fastdebug builds on all platforms as suggested in >> JDK-7195622. Several notes concerning this fix: >> >> 1. A review should start at understanding the changes >> made to oopsHierarchy.hpp >> a. Addition of a non-volatile copy constructor >> to address compile time errors >> reported in JDK-7180556 and also currently >> by g++ compilers on Linux. >> b. Addition of member wise assignment operators >> to handle many instances >> of [non]volatile to [non]volatile oops >> within the JVM. >> Note: Solaris compilers would not allow for >> the member wise assignment operators >> of every flavor of non-volatile to >> volatile and vice versa. However, unlike g++ compilers, >> Solaris compilers had no issue >> passing a volatile "this" pointer to a non-volatile >> assignment operator. So the g++ >> compilers needed these different flavors >> of the assignment operator and >> Solaris did not. >> d. For similar reasons as 1b, addition of a >> volatile explicit conversion from oop -> void *. >> g++ specifically complained when trying to >> pass a volatile "this" pointer. >> e. Removal of the ambiguous behavior of having >> overloaded copy constructor and >> explicit user conversion member functions >> defined of both integral and void *. >> All C++ compilers, except Solaris, issue a >> compile time error concerning this ambiguity. >> >> 2. Change #1e had the consequence of C++ compilers now >> generating compile time >> errors where the practice has been to cast an oop to >> and from an integral type such >> as intptr_t. To allow for this practice to continue, >> when oop is a structure and not >> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS >> is defined, two new >> macros were introduced within globalDefinitions.hpp, >> CAST_TO_OOP and CAST_FROM_OOP. >> >> 3. Due to the change in #1a & #1b, the oop structure in >> no longer considered a POD (plain old data) >> by the g++ compilers on Linux and MacOS. This caused >> several changes to be needed >> throughout the JVM to add an (void *) cast of an oop >> when invoking print_cr(). >> >> 4. Many instances of an assignment to a volatile oop >> required a "const_cast" to >> cast away the volatileness of the lvalue. There is >> already precedence for this >> type of change within utilities/taskqueue.hpp. The >> following comment was in place: >> >> // g++ complains if the volatile result of the assignment is >> // unused, so we cast the volatile away. We cannot cast >> directly >> // to void, because gcc treats that as not using the result >> of the >> // assignment. However, casting to E& means that we >> trigger an >> // unused-value warning. So, we cast the E& to void. >> >> 5. The addition of the volatile keyword to the >> GenericTaskQueue's pop_local() & pop_global() >> member functions was to accommodate the Solaris C++ >> compiler's complaint about the assignment >> of the volatile elements of the private member data >> _elems when GenericTaskQueue is instantiated >> with a non-volatile oop. Line #723 in pop_local(). >> This was a result of #1b, Solaris' lack of >> allowing for all flavors of volatile/non-volatile >> member wise assignment operators. >> Per Liden of the GC group did pre-review this >> specific change with regards to performance >> implications and was not concerned. >> >> 6. In utilities/hashtable.cpp, required >> CHECK_UNHANDLED_OOPS conditional for the instantiation >> of "template class Hashtable". With >> CHECK_UHANDLED_OOPS specified for a >> fastdebug build, an unresolved symbol occurred. >> philli:% nm --demangle >> build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | >> grep seed >> U Hashtable> short)2304>::_seed >> 0000000000848890 t Hashtable> short)256>::seed() >> ... >> >> Making these improvements allows for CHECK_UNHANDLED_OOPS to be >> defined in all fastdebug builds across the supported platforms. >> >> Builds: >> Solaris (12u1 & 12u3 C++ compilers), >> MacOS (llvm-g++ & clang++ compilers), >> Linux (g++ v4.4.3 & g++ v4.7.3), >> VS2010 >> >> Tests: >> JTREG on MacOS, >> vm.quick.testlist on LInux, >> nsk.regression.testlist, nsk.stress.testlist on LInux, >> JCK vm on Windows >> >> Thank you, Lois >> >> >> >> >> >> >> >> >> >> > From lois.foltan at oracle.com Fri Sep 20 06:45:27 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 20 Sep 2013 09:45:27 -0400 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <523C4A97.7070004@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <523C43B4.1050105@oracle.com> <523C4A97.7070004@oracle.com> Message-ID: <523C5177.4040102@oracle.com> On 9/20/2013 9:16 AM, Stefan Karlsson wrote: > On 09/20/2013 02:46 PM, Stefan Karlsson wrote: >> On 09/19/2013 05:13 PM, Lois Foltan wrote: >>> >>> >>> Please review the following fix: >>> Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >> >> The changes looks good. > > I forgot this rather benign bug: > > http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/src/share/vm/oops/klass.inline.hpp.patch > > > inline bool check_klass_alignment(Klass* obj) { > - return (intptr_t)obj % KlassAlignmentInBytes == 0; > + return CAST_FROM_OOP(intptr_t, obj) % KlassAlignmentInBytes == 0; > } Hi Stefan, Thank you, good catch. I will fix this and send it out for a second round of review with my changes to do away of the CAST* macros in favor of inline template methods based on feedback from Christian Thalinger. Lois > > > obj is not an oop. > > thanks, > StefanK > >> >> There are some changes that I don't fully agree with, but I will not >> block the push because of them. I'm just going to mention them here >> for the record: >> >> 1) I would personally prefer not to have the >> CAST_TO_OOP/CAST_FROM_OOP macros and instead explicitly add (void *) >> casts. >> >> 2) I don't understand the need make the code harder to read by adding >> a SOLAR_ONLY((void*)) instead of just a plain (void*). >> >> I'm looking forward to be able to use this feature on Linux! >> >> thanks, >> StefanK >> >>> >>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: >>> Error:Initializing const volatile oop& requires ... & >>> CheckUnhandledOops has limited usefulness now bug links at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>> >>> Summary of fix: >>> >>> Update the C++ oop structure definition in oopsHierarchy.hpp to >>> solve several problems with the current definition when compiled >>> with various C++ compilers across supported platforms. These >>> changes initially address the problem reported in JDK-7180556 and >>> continue with additional improvements to allow CHECK_UNHANDLED_OOPS >>> to be defined in all fastdebug builds on all platforms as suggested >>> in JDK-7195622. Several notes concerning this fix: >>> >>> 1. A review should start at understanding the changes >>> made to oopsHierarchy.hpp >>> a. Addition of a non-volatile copy constructor >>> to address compile time errors >>> reported in JDK-7180556 and also currently >>> by g++ compilers on Linux. >>> b. Addition of member wise assignment operators >>> to handle many instances >>> of [non]volatile to [non]volatile oops >>> within the JVM. >>> Note: Solaris compilers would not allow for >>> the member wise assignment operators >>> of every flavor of non-volatile >>> to volatile and vice versa. However, unlike g++ compilers, >>> Solaris compilers had no issue >>> passing a volatile "this" pointer to a non-volatile >>> assignment operator. So the g++ >>> compilers needed these different flavors >>> of the assignment operator and >>> Solaris did not. >>> d. For similar reasons as 1b, addition of a >>> volatile explicit conversion from oop -> void *. >>> g++ specifically complained when trying to >>> pass a volatile "this" pointer. >>> e. Removal of the ambiguous behavior of having >>> overloaded copy constructor and >>> explicit user conversion member functions >>> defined of both integral and void *. >>> All C++ compilers, except Solaris, issue a >>> compile time error concerning this ambiguity. >>> >>> 2. Change #1e had the consequence of C++ compilers now >>> generating compile time >>> errors where the practice has been to cast an oop to >>> and from an integral type such >>> as intptr_t. To allow for this practice to >>> continue, when oop is a structure and not >>> a OopDesc *, as is the case when >>> CHECK_UNHANDLED_OOPS is defined, two new >>> macros were introduced within globalDefinitions.hpp, >>> CAST_TO_OOP and CAST_FROM_OOP. >>> >>> 3. Due to the change in #1a & #1b, the oop structure in >>> no longer considered a POD (plain old data) >>> by the g++ compilers on Linux and MacOS. This caused >>> several changes to be needed >>> throughout the JVM to add an (void *) cast of an oop >>> when invoking print_cr(). >>> >>> 4. Many instances of an assignment to a volatile oop >>> required a "const_cast" to >>> cast away the volatileness of the lvalue. There is >>> already precedence for this >>> type of change within utilities/taskqueue.hpp. The >>> following comment was in place: >>> >>> // g++ complains if the volatile result of the >>> assignment is >>> // unused, so we cast the volatile away. We cannot cast >>> directly >>> // to void, because gcc treats that as not using the result >>> of the >>> // assignment. However, casting to E& means that we >>> trigger an >>> // unused-value warning. So, we cast the E& to void. >>> >>> 5. The addition of the volatile keyword to the >>> GenericTaskQueue's pop_local() & pop_global() >>> member functions was to accommodate the Solaris C++ >>> compiler's complaint about the assignment >>> of the volatile elements of the private member data >>> _elems when GenericTaskQueue is instantiated >>> with a non-volatile oop. Line #723 in pop_local(). >>> This was a result of #1b, Solaris' lack of >>> allowing for all flavors of volatile/non-volatile >>> member wise assignment operators. >>> Per Liden of the GC group did pre-review this >>> specific change with regards to performance >>> implications and was not concerned. >>> >>> 6. In utilities/hashtable.cpp, required >>> CHECK_UNHANDLED_OOPS conditional for the instantiation >>> of "template class Hashtable". With >>> CHECK_UHANDLED_OOPS specified for a >>> fastdebug build, an unresolved symbol occurred. >>> philli:% nm --demangle >>> build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | >>> grep seed >>> U Hashtable>> short)2304>::_seed >>> 0000000000848890 t Hashtable>> short)256>::seed() >>> ... >>> >>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be >>> defined in all fastdebug builds across the supported platforms. >>> >>> Builds: >>> Solaris (12u1 & 12u3 C++ compilers), >>> MacOS (llvm-g++ & clang++ compilers), >>> Linux (g++ v4.4.3 & g++ v4.7.3), >>> VS2010 >>> >>> Tests: >>> JTREG on MacOS, >>> vm.quick.testlist on LInux, >>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>> JCK vm on Windows >>> >>> Thank you, Lois >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > From roland.westrelin at oracle.com Fri Sep 20 06:52:01 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 20 Sep 2013 15:52:01 +0200 Subject: CFV: New hotspot Group Member: Niclas Adlertz Message-ID: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to Membership in the hotspot Group. Niclas is an Oracle engineer, currently in the compiler team, and has been working on HotSpot for a year. He is a Commiter for the hsx Project and has contributed more than 19 HotSpot changes already, primarily relating to the server compiler register allocator. Votes are due by Friday, October 4, 2013. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Regards, Roland Westrelin [1] http://openjdk.java.net/census/#hotspot [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Fri Sep 20 08:43:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Sep 2013 08:43:40 -0700 Subject: CFV: New hotspot Group Member: Niclas Adlertz In-Reply-To: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> References: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> Message-ID: <523C6D2C.3070400@oracle.com> Vote: yes Vladimir On 9/20/13 6:52 AM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to Membership in the hotspot Group. > > Niclas is an Oracle engineer, currently in the compiler team, and has been working on HotSpot for a year. He is a Commiter for the hsx Project and has contributed more than 19 HotSpot changes already, primarily relating to the server compiler register allocator. > > Votes are due by Friday, October 4, 2013. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Regards, > Roland Westrelin > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > From roland.westrelin at oracle.com Fri Sep 20 08:47:11 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 20 Sep 2013 17:47:11 +0200 Subject: CFV: New hotspot Group Member: Niclas Adlertz In-Reply-To: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> References: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> Message-ID: <736730CA-619F-45CB-BCB8-345F4663B4BF@oracle.com> Vote: yes Roland. On Sep 20, 2013, at 3:52 PM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to Membership in the hotspot Group. > > Niclas is an Oracle engineer, currently in the compiler team, and has been working on HotSpot for a year. He is a Commiter for the hsx Project and has contributed more than 19 HotSpot changes already, primarily relating to the server compiler register allocator. > > Votes are due by Friday, October 4, 2013. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Regards, > Roland Westrelin > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From niclas.adlertz at oracle.com Fri Sep 20 10:26:35 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Fri, 20 Sep 2013 17:26:35 +0000 Subject: hg: hsx/hotspot-main/hotspot: 16 new changesets Message-ID: <20130920172716.145EF629E4@hg.openjdk.java.net> Changeset: 8c83625e3a53 Author: adlertz Date: 2013-09-12 23:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c83625e3a53 8024646: Remove LRG_List container, replace it with GrowableArray Summary: We already have GrowableArray, use it instead of LRG_List Reviewed-by: kvn ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp Changeset: 3a4e6c929bf3 Author: twisti Date: 2013-09-12 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a4e6c929bf3 8024275: During CTW: assert(sig_bt[member_arg_pos] == T_OBJECT) failed: dispatch argument must be an object Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp Changeset: 591b49112612 Author: twisti Date: 2013-09-12 18:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/591b49112612 Merge Changeset: 01b268b3080a Author: vlivanov Date: 2013-09-13 04:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/01b268b3080a 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) Reviewed-by: twisti, kvn, sla ! src/share/tools/LogCompilation/README ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/ostream.cpp Changeset: 69f26e8e09f9 Author: twisti Date: 2013-09-13 16:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69f26e8e09f9 8024760: add more types, fields and constants to VMStructs Reviewed-by: kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ae3e68933caf Author: adlertz Date: 2013-09-17 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ae3e68933caf Merge ! src/share/vm/runtime/arguments.cpp Changeset: 22194f27fbfb Author: ctornqvi Date: 2013-09-17 16:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22194f27fbfb 8014905: [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk Summary: Change JDKToolFinder to look in compile.jdk if the executable cannot be found in test.jdk Reviewed-by: dholmes, hseigel ! test/TEST.groups ! test/gc/TestVerifyDuringStartup.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java Changeset: 2c98370f2611 Author: ctornqvi Date: 2013-09-17 23:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c98370f2611 Merge Changeset: 6d7eba360ba4 Author: anoll Date: 2013-09-17 08:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d7eba360ba4 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase interpreter size for x86 template interpreter Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: a4788ba67e20 Author: adlertz Date: 2013-09-17 16:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a4788ba67e20 Merge Changeset: b2e698d2276c Author: drchase Date: 2013-09-13 22:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2e698d2276c 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation Summary: Enhance method resolution and resulting data structures, plus some refactoring. Reviewed-by: twisti, acorn, jrose ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 67bae56fdd69 Author: jrose Date: 2013-09-17 20:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/67bae56fdd69 Merge Changeset: ab274453d37f Author: anoll Date: 2013-09-18 07:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ab274453d37f 8022883: Assertion failed: sweptCount >= flushedCount + markedCount + zombifiedCount Summary: Provide correct number of visited nmethods to Tracing Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sweeper.cpp Changeset: 04cbe2026912 Author: rbackman Date: 2013-09-18 09:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/04cbe2026912 Merge Changeset: 2795dff62b6c Author: iveresov Date: 2013-09-18 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2795dff62b6c 8023542: Test java/io/File/CheckPermission.java fails due to unfinished recursion (java.lang.StackOverflowError) when JIT'ed code (-client,-server) is running Summary: Move null check before klass reference materialization in checkcast Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: da051ce490eb Author: adlertz Date: 2013-09-19 18:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/da051ce490eb Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp ! test/TEST.groups From christian.thalinger at oracle.com Fri Sep 20 11:32:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 20 Sep 2013 11:32:06 -0700 Subject: CFV: New hotspot Group Member: Niclas Adlertz In-Reply-To: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> References: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> Message-ID: <0C130AF6-99BA-4885-BB49-AAFC49B2C559@oracle.com> Vote: yes On Sep 20, 2013, at 6:52 AM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to Membership in the hotspot Group. > > Niclas is an Oracle engineer, currently in the compiler team, and has been working on HotSpot for a year. He is a Commiter for the hsx Project and has contributed more than 19 HotSpot changes already, primarily relating to the server compiler register allocator. > > Votes are due by Friday, October 4, 2013. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Regards, > Roland Westrelin > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Fri Sep 20 13:01:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 20 Sep 2013 16:01:44 -0400 Subject: RFR 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solari,s 64 Message-ID: <523CA9A8.9000107@oracle.com> Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found. open webrev at http://cr.openjdk.java.net/~coleenp/8014956/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8014956 Tested with nashorn api tests and test in bug (and vm.quick.testlist in progress). Thanks, Coleen From harold.seigel at oracle.com Fri Sep 20 13:25:24 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 20 Sep 2013 16:25:24 -0400 Subject: RFR 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solari,s 64 In-Reply-To: <523CA9A8.9000107@oracle.com> References: <523CA9A8.9000107@oracle.com> Message-ID: <523CAF34.20309@oracle.com> Hi Coleen, Your changes look good. Harold On 9/20/2013 4:01 PM, Coleen Phillmore wrote: > Summary: reference_map[] array had uninitialized junk that was causing > a bogus bootstrap method to be found. > > open webrev at http://cr.openjdk.java.net/~coleenp/8014956/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8014956 > > Tested with nashorn api tests and test in bug (and vm.quick.testlist > in progress). > > Thanks, > Coleen > From lois.foltan at oracle.com Thu Sep 19 15:19:32 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 19 Sep 2013 18:19:32 -0400 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> Message-ID: <523B7874.4040605@oracle.com> On 9/19/2013 6:09 PM, Christian Thalinger wrote: > + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) > + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) > > Could these two macros also be a method? Hi Christian, I assume by method you are implying methods within the oop class itself? That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. Thanks for the initial review, Lois > > On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: > >> >> Please review the following fix: >> Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >> >> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >> CheckUnhandledOops has limited usefulness now bug links at: >> >> https://bugs.openjdk.java.net/browse/JDK-7180556 >> https://bugs.openjdk.java.net/browse/JDK-7195622 >> >> Summary of fix: >> >> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >> >> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >> a. Addition of a non-volatile copy constructor to address compile time errors >> reported in JDK-7180556 and also currently by g++ compilers on Linux. >> b. Addition of member wise assignment operators to handle many instances >> of [non]volatile to [non]volatile oops within the JVM. >> Note: Solaris compilers would not allow for the member wise assignment operators >> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >> assignment operator. So the g++ compilers needed these different flavors >> of the assignment operator and Solaris did not. >> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >> g++ specifically complained when trying to pass a volatile "this" pointer. >> e. Removal of the ambiguous behavior of having overloaded copy constructor and >> explicit user conversion member functions defined of both integral and void *. >> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >> >> 2. Change #1e had the consequence of C++ compilers now generating compile time >> errors where the practice has been to cast an oop to and from an integral type such >> as intptr_t. To allow for this practice to continue, when oop is a structure and not >> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >> >> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >> >> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >> cast away the volatileness of the lvalue. There is already precedence for this >> type of change within utilities/taskqueue.hpp. The following comment was in place: >> >> // g++ complains if the volatile result of the assignment is >> // unused, so we cast the volatile away. We cannot cast >> directly >> // to void, because gcc treats that as not using the result >> of the >> // assignment. However, casting to E& means that we trigger an >> // unused-value warning. So, we cast the E& to void. >> >> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >> allowing for all flavors of volatile/non-volatile member wise assignment operators. >> Per Liden of the GC group did pre-review this specific change with regards to performance >> implications and was not concerned. >> >> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >> fastdebug build, an unresolved symbol occurred. >> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >> U Hashtable::_seed >> 0000000000848890 t Hashtable::seed() >> ... >> >> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >> >> Builds: >> Solaris (12u1 & 12u3 C++ compilers), >> MacOS (llvm-g++ & clang++ compilers), >> Linux (g++ v4.4.3 & g++ v4.7.3), >> VS2010 >> >> Tests: >> JTREG on MacOS, >> vm.quick.testlist on LInux, >> nsk.regression.testlist, nsk.stress.testlist on LInux, >> JCK vm on Windows >> >> Thank you, Lois >> >> >> >> >> >> >> >> >> >> From lois.foltan at oracle.com Thu Sep 19 16:22:17 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 19 Sep 2013 19:22:17 -0400 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> <523B7874.4040605@oracle.com> <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> Message-ID: <523B8729.8090803@oracle.com> On 9/19/2013 6:27 PM, Christian Thalinger wrote: > On Sep 19, 2013, at 3:19 PM, Lois Foltan wrote: > >> On 9/19/2013 6:09 PM, Christian Thalinger wrote: >>> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>> + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>> >>> Could these two macros also be a method? >> Hi Christian, >> I assume by method you are implying methods within the oop class itself? > Not necessarily. We already have a couple of inline methods is globalDefinitions.hpp. Would that work? That would work in the case of CAST_TO_OOP, where the type to cast value to is known, an oop. In the case of CAST_FROM_OOP, it wouldn't work as nicely without having to introduce many different inline methods based on the different types that an oop must be cast to. Lois > >> That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. >> >> Thanks for the initial review, >> Lois >> >>> On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: >>> >>>> Please review the following fix: >>>> Webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >>>> >>>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >>>> CheckUnhandledOops has limited usefulness now bug links at: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>>> >>>> Summary of fix: >>>> >>>> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >>>> >>>> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >>>> a. Addition of a non-volatile copy constructor to address compile time errors >>>> reported in JDK-7180556 and also currently by g++ compilers on Linux. >>>> b. Addition of member wise assignment operators to handle many instances >>>> of [non]volatile to [non]volatile oops within the JVM. >>>> Note: Solaris compilers would not allow for the member wise assignment operators >>>> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >>>> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >>>> assignment operator. So the g++ compilers needed these different flavors >>>> of the assignment operator and Solaris did not. >>>> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >>>> g++ specifically complained when trying to pass a volatile "this" pointer. >>>> e. Removal of the ambiguous behavior of having overloaded copy constructor and >>>> explicit user conversion member functions defined of both integral and void *. >>>> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >>>> >>>> 2. Change #1e had the consequence of C++ compilers now generating compile time >>>> errors where the practice has been to cast an oop to and from an integral type such >>>> as intptr_t. To allow for this practice to continue, when oop is a structure and not >>>> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >>>> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >>>> >>>> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >>>> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >>>> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >>>> >>>> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >>>> cast away the volatileness of the lvalue. There is already precedence for this >>>> type of change within utilities/taskqueue.hpp. The following comment was in place: >>>> >>>> // g++ complains if the volatile result of the assignment is >>>> // unused, so we cast the volatile away. We cannot cast >>>> directly >>>> // to void, because gcc treats that as not using the result >>>> of the >>>> // assignment. However, casting to E& means that we trigger an >>>> // unused-value warning. So, we cast the E& to void. >>>> >>>> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >>>> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >>>> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >>>> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >>>> allowing for all flavors of volatile/non-volatile member wise assignment operators. >>>> Per Liden of the GC group did pre-review this specific change with regards to performance >>>> implications and was not concerned. >>>> >>>> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >>>> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >>>> fastdebug build, an unresolved symbol occurred. >>>> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >>>> U Hashtable::_seed >>>> 0000000000848890 t Hashtable::seed() >>>> ... >>>> >>>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >>>> >>>> Builds: >>>> Solaris (12u1 & 12u3 C++ compilers), >>>> MacOS (llvm-g++ & clang++ compilers), >>>> Linux (g++ v4.4.3 & g++ v4.7.3), >>>> VS2010 >>>> >>>> Tests: >>>> JTREG on MacOS, >>>> vm.quick.testlist on LInux, >>>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>>> JCK vm on Windows >>>> >>>> Thank you, Lois >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From lois.foltan at oracle.com Thu Sep 19 18:06:10 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 19 Sep 2013 21:06:10 -0400 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: <28F5421A-B77B-4675-8A0A-153B0434E71A@oracle.com> References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> <523B7874.4040605@oracle.com> <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> <523B8729.8090803@oracle.com> <28F5421A-B77B-4675-8A0A-153B0434E71A@oracle.com> Message-ID: <523B9F82.6020107@oracle.com> On 9/19/2013 7:25 PM, Christian Thalinger wrote: > On Sep 19, 2013, at 4:22 PM, Lois Foltan wrote: > >> On 9/19/2013 6:27 PM, Christian Thalinger wrote: >>> On Sep 19, 2013, at 3:19 PM, Lois Foltan wrote: >>> >>>> On 9/19/2013 6:09 PM, Christian Thalinger wrote: >>>>> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>>> + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>>> >>>>> Could these two macros also be a method? >>>> Hi Christian, >>>> I assume by method you are implying methods within the oop class itself? >>> Not necessarily. We already have a couple of inline methods is globalDefinitions.hpp. Would that work? >> That would work in the case of CAST_TO_OOP, where the type to cast value to is known, an oop. In the case of CAST_FROM_OOP, it wouldn't work as nicely without having to introduce many different inline methods based on the different types that an oop must be cast to. > How about a template method? Hi Christian, I had to prototype this idea, here's the implementation I came up with template inline oop cast_to_oop(T value) { return (oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))value); } template inline T cast_from_oop(oop& o) { return (T)(CHECK_UNHANDLED_OOPS_ONLY((void*))o); } The cast_from_oop() template method vs. the CAST_FROM_OOP() macro is a wash, in that no extra copy construction was incurred. The cast_to_oop() template method vs. the CAST_TO_OOP() macro was not. There was one extra call to the (void *) conversion operator and an extra copy construction. I believe this can be attributed to the return of the oop since the temporary oop that was constructed could not be returned by reference since it is a temporary, thus an extra copy construction occurred to return it by value. Given the extra copy construction, it is better to stick with the macros. Thanks, Lois > >> Lois >>>> That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. >>>> >>>> Thanks for the initial review, >>>> Lois >>>> >>>>> On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: >>>>> >>>>>> Please review the following fix: >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >>>>>> >>>>>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >>>>>> CheckUnhandledOops has limited usefulness now bug links at: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>>>>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>>>>> >>>>>> Summary of fix: >>>>>> >>>>>> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >>>>>> >>>>>> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >>>>>> a. Addition of a non-volatile copy constructor to address compile time errors >>>>>> reported in JDK-7180556 and also currently by g++ compilers on Linux. >>>>>> b. Addition of member wise assignment operators to handle many instances >>>>>> of [non]volatile to [non]volatile oops within the JVM. >>>>>> Note: Solaris compilers would not allow for the member wise assignment operators >>>>>> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >>>>>> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >>>>>> assignment operator. So the g++ compilers needed these different flavors >>>>>> of the assignment operator and Solaris did not. >>>>>> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >>>>>> g++ specifically complained when trying to pass a volatile "this" pointer. >>>>>> e. Removal of the ambiguous behavior of having overloaded copy constructor and >>>>>> explicit user conversion member functions defined of both integral and void *. >>>>>> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >>>>>> >>>>>> 2. Change #1e had the consequence of C++ compilers now generating compile time >>>>>> errors where the practice has been to cast an oop to and from an integral type such >>>>>> as intptr_t. To allow for this practice to continue, when oop is a structure and not >>>>>> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >>>>>> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >>>>>> >>>>>> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >>>>>> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >>>>>> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >>>>>> >>>>>> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >>>>>> cast away the volatileness of the lvalue. There is already precedence for this >>>>>> type of change within utilities/taskqueue.hpp. The following comment was in place: >>>>>> >>>>>> // g++ complains if the volatile result of the assignment is >>>>>> // unused, so we cast the volatile away. We cannot cast >>>>>> directly >>>>>> // to void, because gcc treats that as not using the result >>>>>> of the >>>>>> // assignment. However, casting to E& means that we trigger an >>>>>> // unused-value warning. So, we cast the E& to void. >>>>>> >>>>>> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >>>>>> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >>>>>> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >>>>>> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >>>>>> allowing for all flavors of volatile/non-volatile member wise assignment operators. >>>>>> Per Liden of the GC group did pre-review this specific change with regards to performance >>>>>> implications and was not concerned. >>>>>> >>>>>> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >>>>>> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >>>>>> fastdebug build, an unresolved symbol occurred. >>>>>> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >>>>>> U Hashtable::_seed >>>>>> 0000000000848890 t Hashtable::seed() >>>>>> ... >>>>>> >>>>>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >>>>>> >>>>>> Builds: >>>>>> Solaris (12u1 & 12u3 C++ compilers), >>>>>> MacOS (llvm-g++ & clang++ compilers), >>>>>> Linux (g++ v4.4.3 & g++ v4.7.3), >>>>>> VS2010 >>>>>> >>>>>> Tests: >>>>>> JTREG on MacOS, >>>>>> vm.quick.testlist on LInux, >>>>>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>>>>> JCK vm on Windows >>>>>> >>>>>> Thank you, Lois >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From lois.foltan at oracle.com Fri Sep 20 04:22:50 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 20 Sep 2013 07:22:50 -0400 Subject: RFR (L) JDK-7195622: CheckUnhandledOops has limited usefulness now In-Reply-To: References: <523B13F0.1040105@oracle.com> <523B14AC.5040509@oracle.com> <3DCB255B-9DE4-49E4-9DFE-09001241D2AA@oracle.com> <523B7874.4040605@oracle.com> <0EE8E7CF-3661-4B73-B43E-EA002EF7F955@oracle.com> <523B8729.8090803@oracle.com> <28F5421A-B77B-4675-8A0A-153B0434E71A@oracle.com> <523B9F82.6020107@oracle.com> Message-ID: <523C300A.9010101@oracle.com> On 9/19/2013 9:34 PM, Christian Thalinger wrote: > > On Sep 19, 2013, at 6:06 PM, Lois Foltan > wrote: > >> >> On 9/19/2013 7:25 PM, Christian Thalinger wrote: >>> On Sep 19, 2013, at 4:22 PM, Lois Foltan wrote: >>> >>>> On 9/19/2013 6:27 PM, Christian Thalinger wrote: >>>>> On Sep 19, 2013, at 3:19 PM, Lois Foltan wrote: >>>>> >>>>>> On 9/19/2013 6:09 PM, Christian Thalinger wrote: >>>>>>> + #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>>>>> + #define CAST_FROM_OOP(new_type, value) ((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value))) >>>>>>> >>>>>>> Could these two macros also be a method? >>>>>> Hi Christian, >>>>>> I assume by method you are implying methods within the oop class itself? >>>>> Not necessarily. We already have a couple of inline methods is globalDefinitions.hpp. Would that work? >>>> That would work in the case of CAST_TO_OOP, where the type to cast value to is known, an oop. In the case of CAST_FROM_OOP, it wouldn't work as nicely without having to introduce many different inline methods based on the different types that an oop must be cast to. >>> How about a template method? >> Hi Christian, >> I had to prototype this idea, here's the implementation I came up with >> >> template inline oop cast_to_oop(T value) { >> return (oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))value); >> } >> template inline T cast_from_oop(oop& o) { >> return (T)(CHECK_UNHANDLED_OOPS_ONLY((void*))o); >> } >> >> The cast_from_oop() template method vs. the CAST_FROM_OOP() macro is >> a wash, in that no extra copy construction was incurred. The >> cast_to_oop() template method vs. the CAST_TO_OOP() macro was not. >> There was one extra call to the (void *) conversion operator and an >> extra copy construction. I believe this can be attributed to the >> return of the oop since the temporary oop that was constructed could >> not be returned by reference since it is a temporary, thus an extra >> copy construction occurred to return it by value. Given the extra >> copy construction, it is better to stick with the macros. > > But this is only when CHECK_UNHANDLED_OOPS is on, right? In a product > there can't be a copy construction. If that's the case I'd say we go > with the template method because the tiny overhead in a fastdebug > build is negligible. Hi Christian, Okay, I concur. Seems like Coleen is okay with the template approach as well. I will switch over to implement the template and send this out for another review once I'm done. Thanks, Lois > >> >> Thanks, >> Lois >>>> Lois >>>>>> That would work only in the case of fastdebug builds where an oop is defined as a class. In non-fastdebug builds, an oop is a (oopDesc *). The macros provided a way to preserve the existing cast to & from an oop to a numerical type in all builds, even non-fastdebug ones. >>>>>> >>>>>> Thanks for the initial review, >>>>>> Lois >>>>>> >>>>>>> On Sep 19, 2013, at 8:13 AM, Lois Foltan wrote: >>>>>>> >>>>>>>> Please review the following fix: >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/ >>>>>>>> >>>>>>>> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >>>>>>>> CheckUnhandledOops has limited usefulness now bug links at: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7180556 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195622 >>>>>>>> >>>>>>>> Summary of fix: >>>>>>>> >>>>>>>> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >>>>>>>> >>>>>>>> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >>>>>>>> a. Addition of a non-volatile copy constructor to address compile time errors >>>>>>>> reported in JDK-7180556 and also currently by g++ compilers on Linux. >>>>>>>> b. Addition of member wise assignment operators to handle many instances >>>>>>>> of [non]volatile to [non]volatile oops within the JVM. >>>>>>>> Note: Solaris compilers would not allow for the member wise assignment operators >>>>>>>> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >>>>>>>> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >>>>>>>> assignment operator. So the g++ compilers needed these different flavors >>>>>>>> of the assignment operator and Solaris did not. >>>>>>>> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >>>>>>>> g++ specifically complained when trying to pass a volatile "this" pointer. >>>>>>>> e. Removal of the ambiguous behavior of having overloaded copy constructor and >>>>>>>> explicit user conversion member functions defined of both integral and void *. >>>>>>>> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >>>>>>>> >>>>>>>> 2. Change #1e had the consequence of C++ compilers now generating compile time >>>>>>>> errors where the practice has been to cast an oop to and from an integral type such >>>>>>>> as intptr_t. To allow for this practice to continue, when oop is a structure and not >>>>>>>> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >>>>>>>> macros were introduced within globalDefinitions.hpp, CAST_TO_OOP and CAST_FROM_OOP. >>>>>>>> >>>>>>>> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >>>>>>>> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >>>>>>>> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >>>>>>>> >>>>>>>> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >>>>>>>> cast away the volatileness of the lvalue. There is already precedence for this >>>>>>>> type of change within utilities/taskqueue.hpp. The following comment was in place: >>>>>>>> >>>>>>>> // g++ complains if the volatile result of the assignment is >>>>>>>> // unused, so we cast the volatile away. We cannot cast >>>>>>>> directly >>>>>>>> // to void, because gcc treats that as not using the result >>>>>>>> of the >>>>>>>> // assignment. However, casting to E& means that we trigger an >>>>>>>> // unused-value warning. So, we cast the E& to void. >>>>>>>> >>>>>>>> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >>>>>>>> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >>>>>>>> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >>>>>>>> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >>>>>>>> allowing for all flavors of volatile/non-volatile member wise assignment operators. >>>>>>>> Per Liden of the GC group did pre-review this specific change with regards to performance >>>>>>>> implications and was not concerned. >>>>>>>> >>>>>>>> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >>>>>>>> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >>>>>>>> fastdebug build, an unresolved symbol occurred. >>>>>>>> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >>>>>>>> U Hashtable::_seed >>>>>>>> 0000000000848890 t Hashtable::seed() >>>>>>>> ... >>>>>>>> >>>>>>>> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >>>>>>>> >>>>>>>> Builds: >>>>>>>> Solaris (12u1 & 12u3 C++ compilers), >>>>>>>> MacOS (llvm-g++ & clang++ compilers), >>>>>>>> Linux (g++ v4.4.3 & g++ v4.7.3), >>>>>>>> VS2010 >>>>>>>> >>>>>>>> Tests: >>>>>>>> JTREG on MacOS, >>>>>>>> vm.quick.testlist on LInux, >>>>>>>> nsk.regression.testlist, nsk.stress.testlist on LInux, >>>>>>>> JCK vm on Windows >>>>>>>> >>>>>>>> Thank you, Lois >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> > From daniel.daugherty at oracle.com Fri Sep 20 14:07:18 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 20 Sep 2013 15:07:18 -0600 Subject: RFR 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solari,s 64 In-Reply-To: <523CA9A8.9000107@oracle.com> References: <523CA9A8.9000107@oracle.com> Message-ID: <523CB906.9000604@oracle.com> On 9/20/13 2:01 PM, Coleen Phillmore wrote: > Summary: reference_map[] array had uninitialized junk that was causing > a bogus bootstrap method to be found. > > open webrev at http://cr.openjdk.java.net/~coleenp/8014956/ Thumbs up! src/share/vm/oops/constantPool.hpp No comments. src/share/vm/oops/constantPool.cpp No comments. > bug link at http://bugs.sun.com/view_bug.do?bug_id=8014956 Time to change bug tracking links: https://bugs.openjdk.java.net/browse/JDK-8014956 Dan > > Tested with nashorn api tests and test in bug (and vm.quick.testlist > in progress). > > Thanks, > Coleen > > > From serguei.spitsyn at oracle.com Fri Sep 20 14:16:46 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Sep 2013 14:16:46 -0700 Subject: RFR 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solari,s 64 In-Reply-To: <523CA9A8.9000107@oracle.com> References: <523CA9A8.9000107@oracle.com> Message-ID: <523CBB3E.3000509@oracle.com> Looks good. Thanks, Serguei On 9/20/13 1:01 PM, Coleen Phillmore wrote: > Summary: reference_map[] array had uninitialized junk that was causing > a bogus bootstrap method to be found. > > open webrev at http://cr.openjdk.java.net/~coleenp/8014956/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8014956 > > Tested with nashorn api tests and test in bug (and vm.quick.testlist > in progress). > > Thanks, > Coleen > From alejandro.murillo at oracle.com Fri Sep 20 15:08:17 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 20 Sep 2013 22:08:17 +0000 Subject: hg: hsx/hsx25/hotspot: 76 new changesets Message-ID: <20130920221115.3ADD4629F2@hg.openjdk.java.net> Changeset: 34aa07e92d22 Author: cl Date: 2013-09-19 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/34aa07e92d22 Added tag jdk8-b108 for changeset 85072013aad4 ! .hgtags Changeset: e42e456fbe6e Author: amurillo Date: 2013-09-13 00:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e42e456fbe6e 8024764: new hotspot build - hs25-b51 Reviewed-by: jcoomes ! make/hotspot_version Changeset: baa7927dfbd2 Author: zgu Date: 2013-09-04 08:55 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/baa7927dfbd2 8022798: "assert(seq > 0) failed: counter overflow" in Kitchensink Summary: Removed incorrect assertion, sequence number can overflow Reviewed-by: dholmes, kamg ! src/share/vm/services/memPtr.cpp Changeset: 38f750491293 Author: iklam Date: 2013-09-06 08:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/38f750491293 8022335: Native stack walk while generating hs_err does not work on Windows x64 Summary: Use WinDbg API StackWalk64() Reviewed-by: zgu, dholmes ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 592520c14121 Author: kevinw Date: 2013-09-09 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/592520c14121 8023478: Test fails with HS crash in GCNotifier. Reviewed-by: sla ! src/share/vm/services/gcNotifier.cpp Changeset: b6767a18b379 Author: hseigel Date: 2013-09-09 14:44 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b6767a18b379 8023167: JVM allows duplicate Runtime[In]VisibleTypeAnnotations attributes in ClassFile/field_info/method_info structures Summary: Add checks for duplicates and issue errors when detected. Reviewed-by: coleenp, zgu ! src/share/vm/classfile/classFileParser.cpp Changeset: 0f648fbe4404 Author: dsamersoff Date: 2013-09-11 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f648fbe4404 8024056: runtime/InitialThreadOverflow/testme.sh fails Summary: on some macines gcc not able to link cxx program Reviewed-by: dholmes ! test/runtime/InitialThreadOverflow/testme.sh Changeset: 1c6b721a3fbf Author: dsamersoff Date: 2013-09-12 15:53 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1c6b721a3fbf 8022617: Openjdk hotspot build is broken on BSD platforms using gcc Summary: Enforce of preprocessing of all assembly sources by assembler-with-cpp Reviewed-by: dholmes, erikj ! make/bsd/makefiles/gcc.make Changeset: 225cedaf9a4b Author: zgu Date: 2013-09-13 10:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/225cedaf9a4b Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 623d923529df Author: mgronlun Date: 2013-09-13 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/623d923529df 8021353: Event based tracing is missing thread exit Reviewed-by: allwin, acorn, dcubed, dholmes, egahlin ! src/share/vm/runtime/thread.cpp ! src/share/vm/trace/traceMacros.hpp Changeset: b89a1a870965 Author: mgronlun Date: 2013-09-13 19:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b89a1a870965 Merge ! src/share/vm/runtime/thread.cpp Changeset: ff8a09595db3 Author: sspitsyn Date: 2013-09-13 12:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ff8a09595db3 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed Summary: Handle pending exceptions instead of firing a guarantee() Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: ce5ee9de50ce Author: sspitsyn Date: 2013-09-13 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ce5ee9de50ce 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 0d3ff4d36a31 Author: sspitsyn Date: 2013-09-13 12:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0d3ff4d36a31 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b135b600a66c Author: sspitsyn Date: 2013-09-13 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b135b600a66c Merge Changeset: 2e6938dd68f2 Author: dholmes Date: 2013-09-16 07:38 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2e6938dd68f2 6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock Summary: Associate CLOCK_MONOTONIC with the pthread_cond_t objects used for relative timed waits Reviewed-by: dcubed, shade ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 4472884d8b37 Author: dcubed Date: 2013-09-16 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4472884d8b37 6986195: correctly identify Ubuntu as the operating system in crash report instead of "Debian" Summary: Cleanup and document how various Linux release info files are used by print_distro_info(). Reviewed-by: dcubed, dsamersoff, coleenp, iklam, omajid Contributed-by: gerald.thornbrugh at oracle.com ! src/os/linux/vm/os_linux.cpp Changeset: 42863137168c Author: acorn Date: 2013-09-16 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/42863137168c 8024647: Default method resolution with private superclass method Reviewed-by: kamg, minqi ! src/share/vm/classfile/defaultMethods.cpp Changeset: 921967020b3b Author: acorn Date: 2013-09-16 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/921967020b3b Merge Changeset: 621eda7235d2 Author: minqi Date: 2013-09-16 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/621eda7235d2 7164841: Improvements to the GC log file rotation Summary: made changes to easily identify current log file in rotation. Parameterize the input with %t for time replacement in file name. Reviewed-by: ccheung, tschatzl, tamao, zgu Contributed-by: yumin.qi at oracle.com ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 535973ddf22c Author: minqi Date: 2013-09-16 18:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/535973ddf22c Merge Changeset: 88d6b9a1c27c Author: mseledtsov Date: 2013-09-17 20:09 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/88d6b9a1c27c 8016029: test runtime/6878713/Test6878713.sh failed Summary: Rewrote test in Java; updated the test condition to reflect latest changes in the source Reviewed-by: dholmes, ctornqvi - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar + test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java + test/runtime/ClassFile/testcase.jar Changeset: 6f45933aef35 Author: mseledtsov Date: 2013-09-17 20:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6f45933aef35 7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test Summary: Re-wrote in Java, this also eliminated temporary result file; set upper limit on malloc'd memory Reviewed-by: dcubed, dholmes, ccheung - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar + test/runtime/ClassFile/JsrRewriting.java + test/runtime/ClassFile/JsrRewritingTestCase.jar Changeset: 41e6ae9f6dd7 Author: zgu Date: 2013-09-18 12:52 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/41e6ae9f6dd7 Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: 8e94527f601e Author: bpittore Date: 2013-09-11 20:03 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8e94527f601e 8024007: Misc. cleanup of static agent code Summary: Minor cleanup of static agent code from 8014135 Reviewed-by: dcubed, sspitsyn ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp Changeset: de88570fabfc Author: dholmes Date: 2013-09-11 00:38 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/de88570fabfc 8024256: Minimal VM build is broken with PCH disabled Reviewed-by: coleenp, twisti ! make/excludeSrc.make ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 4c9d415db1c5 Author: dholmes Date: 2013-09-11 23:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4c9d415db1c5 Merge Changeset: b1491b0303ee Author: bdelsart Date: 2013-09-13 07:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b1491b0303ee Merge Changeset: 10efeefa6485 Author: dholmes Date: 2013-09-13 21:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/10efeefa6485 8024505: [TESTBUG] update test groups for additional tests that can't run on the minimal VM Reviewed-by: coleenp, hseigel ! test/TEST.groups Changeset: cc5b40a76049 Author: bdelsart Date: 2013-09-18 21:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cc5b40a76049 Merge ! src/share/vm/runtime/thread.cpp Changeset: 7944aba7ba41 Author: ehelin Date: 2013-08-12 17:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7944aba7ba41 8015107: NPG: Use consistent naming for metaspace concepts Reviewed-by: coleenp, mgerdin, hseigel ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp + test/gc/arguments/TestCompressedClassFlags.java - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java + test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java ! test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 440edcf30231 Author: mgerdin Date: 2013-09-11 08:57 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/440edcf30231 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 Summary: The code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden because compressed oops and compressed klasses has used the same base address in the past. Reviewed-by: sla, jmasa Contributed-by: stefan.johansson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java Changeset: f7bc2ab5f659 Author: tschatzl Date: 2013-09-11 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f7bc2ab5f659 8016825: Large pages for the heap broken on Windows for compressed oops Summary: Correctly pass the requested base address for the heap to the OS function to reserve memory. Reviewed-by: brutisso, stefank ! src/os/windows/vm/os_windows.cpp Changeset: ff218fdb30ba Author: tschatzl Date: 2013-09-11 10:19 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ff218fdb30ba 8021823: G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs Summary: Correctly calculate the initialization value for the shift between object start and bitmap bit in the G1 mark bitmaps. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp + test/gc/TestObjectAlignment.java Changeset: 040895ec3920 Author: tschatzl Date: 2013-09-11 12:03 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/040895ec3920 Merge Changeset: 24e87613ee58 Author: mgerdin Date: 2013-09-11 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/24e87613ee58 8009561: NPG: Metaspace fragmentation when retiring a Metachunk Summary: Use best-fit block-splitting freelist allocation from the block freelist. Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.cpp Changeset: 6608fa23708f Author: mgerdin Date: 2013-09-11 06:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6608fa23708f Merge Changeset: 40136aa2cdb1 Author: tschatzl Date: 2013-09-11 16:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/40136aa2cdb1 8010722: assert: failed: heap size is too big for compressed oops Summary: Use conservative assumptions of required alignment for the various garbage collector components into account when determining the maximum heap size that supports compressed oops. Using this conservative value avoids several circular dependencies in the calculation. Reviewed-by: stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp + test/gc/arguments/TestUseCompressedOopsErgo.java + test/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b82260e84582 Author: tschatzl Date: 2013-09-11 18:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b82260e84582 Merge Changeset: d6c266999345 Author: ehelin Date: 2013-09-12 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d6c266999345 8023476: Metaspace capacity > reserved Reviewed-by: stefank, hseigel, mgerdin ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp Changeset: c4c768305a8f Author: stefank Date: 2013-09-12 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c4c768305a8f 8024638: Count and expose the amount of committed memory in the metaspaces Reviewed-by: brutisso, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 335b388c4b28 Author: stefank Date: 2013-09-13 22:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/335b388c4b28 8024651: Remove the incorrect usage of Metablock::overhead() Reviewed-by: brutisso, mgerdin, coleenp, jmasa ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metaspace.cpp Changeset: 9e11762cee52 Author: stefank Date: 2013-09-13 22:22 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9e11762cee52 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize Reviewed-by: jwilhelm, brutisso, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/metaspace/TestMetaspaceSizeFlags.java ! test/testlibrary/OutputAnalyzerTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java Changeset: 8227700da288 Author: stefank Date: 2013-09-13 22:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8227700da288 8024751: Fix bugs in TraceMetadata Reviewed-by: jmasa, brutisso ! src/share/vm/memory/metaspace.cpp Changeset: 8c5e6482cbfc Author: stefank Date: 2013-09-13 22:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8c5e6482cbfc 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty Reviewed-by: brutisso, mgerdin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 9cb63cd234a0 Author: shade Date: 2013-09-13 07:57 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9cb63cd234a0 8024671: G1 generates assert error messages in product builds Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 884ed7a10f09 Author: tschatzl Date: 2013-09-16 09:41 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/884ed7a10f09 Merge ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/globals.hpp Changeset: 23ae5a04724d Author: tschatzl Date: 2013-09-16 10:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/23ae5a04724d 8024396: VM crashing with assert(!UseLargePages || UseParallelOldGC || use_large_pages) failed: Wrong alignment to use large pages Summary: Loosen wrong assert for UseParallelOldGC to UseParallelGC Reviewed-by: stefank, brutisso ! src/share/vm/memory/universe.cpp + test/gc/arguments/TestAlignmentToUseLargePages.java Changeset: f9b58dbeab91 Author: tschatzl Date: 2013-09-16 13:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9b58dbeab91 Merge Changeset: 17deed6716af Author: tschatzl Date: 2013-09-17 12:04 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/17deed6716af 8024914: Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp Summary: Incorrect usage of idx_t where bm_word_t is appropriate. Reviewed-by: tschatzl, brutisso Contributed-by: Dan Horak ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 5767996b7b7b Author: jwilhelm Date: 2013-09-17 14:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5767996b7b7b 8024884: Test name changed, test list not updated Summary: Updated the test list with the new test name. Reviewed-by: brutisso, ehelin ! test/TEST.groups Changeset: fac394091d73 Author: jwilhelm Date: 2013-09-18 00:08 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fac394091d73 Merge Changeset: 73d0d0218068 Author: ehelin Date: 2013-09-17 20:59 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/73d0d0218068 8024718: Metaspace performance counters and memory pools should report the same data Reviewed-by: stefank, dholmes, coleenp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryUsage.hpp ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java + test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/testlibrary/com/oracle/java/testlibrary/InputArguments.java Changeset: 2f426063daea Author: tschatzl Date: 2013-09-18 10:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2f426063daea 8024662: gc/arguments/TestUseCompressedOopsErgo.java does not compile. Summary: Fix compilation error and use of an outdated VM option in the test Reviewed-by: stefank, jwilhelm ! test/gc/arguments/TestUseCompressedOopsErgoTools.java Changeset: 9044964f9163 Author: tschatzl Date: 2013-09-18 13:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9044964f9163 8024669: Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9 Summary: After changes in 8010722 the ergonomics for calculating the size of the heap that supports zero based compressed oops changed. This lead to the VM actually using zero based compressed oops. Due to low default HeapBaseMinAddress, the OS mapping in the application image at the same address, and limitations of the malloc implementation on Solaris this resulted in very little C heap available for the VM. So the VM immediately gives a native OOME when the machine has lots of physical memory (>=32G). The solution is to increase the HeapBaseMinAddress so that the VM has enough C heap. Reviewed-by: kvn, brutisso ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp Changeset: 719e886d4f72 Author: tschatzl Date: 2013-09-18 15:59 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/719e886d4f72 Merge Changeset: 06ae47d9d088 Author: tschatzl Date: 2013-09-19 09:26 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/06ae47d9d088 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 179cd89fb279 Author: tschatzl Date: 2013-09-19 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/179cd89fb279 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! test/TEST.groups Changeset: 8c83625e3a53 Author: adlertz Date: 2013-09-12 23:13 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8c83625e3a53 8024646: Remove LRG_List container, replace it with GrowableArray Summary: We already have GrowableArray, use it instead of LRG_List Reviewed-by: kvn ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp Changeset: 3a4e6c929bf3 Author: twisti Date: 2013-09-12 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a4e6c929bf3 8024275: During CTW: assert(sig_bt[member_arg_pos] == T_OBJECT) failed: dispatch argument must be an object Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp Changeset: 591b49112612 Author: twisti Date: 2013-09-12 18:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/591b49112612 Merge Changeset: 01b268b3080a Author: vlivanov Date: 2013-09-13 04:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/01b268b3080a 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) Reviewed-by: twisti, kvn, sla ! src/share/tools/LogCompilation/README ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/ostream.cpp Changeset: 69f26e8e09f9 Author: twisti Date: 2013-09-13 16:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69f26e8e09f9 8024760: add more types, fields and constants to VMStructs Reviewed-by: kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ae3e68933caf Author: adlertz Date: 2013-09-17 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ae3e68933caf Merge ! src/share/vm/runtime/arguments.cpp Changeset: 22194f27fbfb Author: ctornqvi Date: 2013-09-17 16:55 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22194f27fbfb 8014905: [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk Summary: Change JDKToolFinder to look in compile.jdk if the executable cannot be found in test.jdk Reviewed-by: dholmes, hseigel ! test/TEST.groups ! test/gc/TestVerifyDuringStartup.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java Changeset: 2c98370f2611 Author: ctornqvi Date: 2013-09-17 23:12 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c98370f2611 Merge Changeset: 6d7eba360ba4 Author: anoll Date: 2013-09-17 08:39 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6d7eba360ba4 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase interpreter size for x86 template interpreter Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: a4788ba67e20 Author: adlertz Date: 2013-09-17 16:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a4788ba67e20 Merge Changeset: b2e698d2276c Author: drchase Date: 2013-09-13 22:38 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b2e698d2276c 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation Summary: Enhance method resolution and resulting data structures, plus some refactoring. Reviewed-by: twisti, acorn, jrose ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 67bae56fdd69 Author: jrose Date: 2013-09-17 20:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/67bae56fdd69 Merge Changeset: ab274453d37f Author: anoll Date: 2013-09-18 07:22 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ab274453d37f 8022883: Assertion failed: sweptCount >= flushedCount + markedCount + zombifiedCount Summary: Provide correct number of visited nmethods to Tracing Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sweeper.cpp Changeset: 04cbe2026912 Author: rbackman Date: 2013-09-18 09:31 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/04cbe2026912 Merge Changeset: 2795dff62b6c Author: iveresov Date: 2013-09-18 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2795dff62b6c 8023542: Test java/io/File/CheckPermission.java fails due to unfinished recursion (java.lang.StackOverflowError) when JIT'ed code (-client,-server) is running Summary: Move null check before klass reference materialization in checkcast Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: da051ce490eb Author: adlertz Date: 2013-09-19 18:01 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/da051ce490eb Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp ! test/TEST.groups Changeset: 566db1b0e6ef Author: amurillo Date: 2013-09-20 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/566db1b0e6ef Merge - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: bf13c3da3d11 Author: amurillo Date: 2013-09-20 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf13c3da3d11 Added tag hs25-b51 for changeset 566db1b0e6ef ! .hgtags From coleen.phillimore at oracle.com Fri Sep 20 15:36:00 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 20 Sep 2013 18:36:00 -0400 Subject: RFR 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solari,s 64 In-Reply-To: <523CBB3E.3000509@oracle.com> References: <523CA9A8.9000107@oracle.com> <523CBB3E.3000509@oracle.com> Message-ID: <523CCDD0.9050604@oracle.com> Thanks Serguei, Dan and Harold. Coleen On 9/20/2013 5:16 PM, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, > Serguei > > On 9/20/13 1:01 PM, Coleen Phillmore wrote: >> Summary: reference_map[] array had uninitialized junk that was >> causing a bogus bootstrap method to be found. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8014956/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8014956 >> >> Tested with nashorn api tests and test in bug (and vm.quick.testlist >> in progress). >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Fri Sep 20 15:40:00 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 20 Sep 2013 18:40:00 -0400 Subject: RFR 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solari,s 64 In-Reply-To: <523CBB3E.3000509@oracle.com> References: <523CA9A8.9000107@oracle.com> <523CBB3E.3000509@oracle.com> Message-ID: <523CCEC0.6000100@oracle.com> Thanks again - I also ran the jdk java/lang/invoke tests. Coleen On 9/20/2013 5:16 PM, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, > Serguei > > On 9/20/13 1:01 PM, Coleen Phillmore wrote: >> Summary: reference_map[] array had uninitialized junk that was >> causing a bogus bootstrap method to be found. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8014956/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8014956 >> >> Tested with nashorn api tests and test in bug (and vm.quick.testlist >> in progress). >> >> Thanks, >> Coleen >> > From jon.masamitsu at oracle.com Fri Sep 20 15:49:13 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 20 Sep 2013 15:49:13 -0700 Subject: Review request: 8025096: Move the ChunkManager instances out of the VirtualSpaceLists In-Reply-To: <523BF115.9050702@oracle.com> References: <523B5522.8020207@oracle.com> <523BF115.9050702@oracle.com> Message-ID: <523CD0E9.4090009@oracle.com> Stefan, Would you consider changing _chunk_manager_class to _chunk_manager_compressed_classes? It is long but it reminds me what exactly it is. metaspace.cpp 651 size_t small_chunk_size() { return (size_t) is_class() ? ClassSmallChunk : SmallChunk; } Can you have 3 arrays of chunks sizes _specialized[] = {SpecializedChunk, SpecializedChunk} _small_chunks[] = {ClassSmallChunk, SmallChunk} _meduim_chunks[] = {ClassMediumChunk, MediumChunk} and then the static static size_t small_chunk_size() { return _small_chunks[_index_of_mdtype]; } Does purge() work for compressed class space? > void Metaspace::purge() { > MutexLockerEx cl(SpaceManager::expand_lock(), > Mutex::_no_safepoint_check_flag); > purge(NonClassType); > if (using_class_space()) { > purge(ClassType); > } > } Is compressed class space still supported by a single VirtualSpace? I think the idea behind purge() is to check for VirtualSpaces that are filled with unused chunks and release the VirtualSpace. Jon On 9/19/2013 11:54 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025096/webrev.01/ > > New webrev based on Coleen's comments. > > Changes: > - Moved the _vs_list pointer out from SpaceManager > - Removed the unused _medium_chunk_bunch field. > > thanks, > StefanK > > On 9/19/13 9:48 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025096/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8025096 >> >> In the fix for 'JDK-8024547 >> : MaxMetaspaceSize >> should limit the committed memory used by the metaspaces' we need to >> make a clearer distinction between when new memory is committed and >> when memory is allocated inside already committed memory. >> >> Moving the ChunkManager, which handles the free chunk list, out of >> the VirtualSpaceList, which handles the committed metaspace memory, >> is a step in that direction. >> >> Changes: >> - Move the ChunkManager instances from VirtualSpaceList to SpaceManager. >> - Move the inc_container_count() into ChunkManager::free_chunks_get. >> Now the Chunk manager calls dec_container_count when chunks are >> inserted in the chunk free list and inc_container_count when chunks >> are removed from the chunk free list. >> - Moved the ChunkManager::chunk_freelist_allocate() call out from the >> VirtualSpaceList::get_new_chunk() >> >> thanks, >> StefanK > From alejandro.murillo at oracle.com Fri Sep 20 18:02:38 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 21 Sep 2013 01:02:38 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130921010250.9D4F1629F6@hg.openjdk.java.net> Changeset: 34aa07e92d22 Author: cl Date: 2013-09-19 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/34aa07e92d22 Added tag jdk8-b108 for changeset 85072013aad4 ! .hgtags Changeset: 566db1b0e6ef Author: amurillo Date: 2013-09-20 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/566db1b0e6ef Merge - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: bf13c3da3d11 Author: amurillo Date: 2013-09-20 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf13c3da3d11 Added tag hs25-b51 for changeset 566db1b0e6ef ! .hgtags Changeset: 8a6a85321d3a Author: amurillo Date: 2013-09-20 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8a6a85321d3a 8025127: new hotspot build - hs25-b52 Reviewed-by: jcoomes ! make/hotspot_version From john.r.rose at oracle.com Fri Sep 20 18:22:41 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 20 Sep 2013 18:22:41 -0700 Subject: CFV: New hotspot Group Member: Niclas Adlertz In-Reply-To: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> References: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> Message-ID: <67E7AC08-7D5F-4A92-B1C0-58C481CF8FB4@oracle.com> Vote: yes From staffan.larsen at oracle.com Sun Sep 22 12:23:25 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Sun, 22 Sep 2013 19:23:25 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20130922192338.B73CF62A29@hg.openjdk.java.net> Changeset: b56a422bcdde Author: sla Date: 2013-09-22 06:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b56a422bcdde 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" Reviewed-by: sla, dsamersoff Contributed-by: Yasumasa Suenaga ! src/share/vm/services/attachListener.cpp Changeset: ee9355903a26 Author: sla Date: 2013-08-29 11:05 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ee9355903a26 8023720: (hotspot) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes, rbackman ! src/os/posix/vm/os_posix.cpp From igor.veresov at oracle.com Mon Sep 23 04:12:42 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 23 Sep 2013 15:12:42 +0400 Subject: CFV: New hotspot Group Member: Niclas Adlertz In-Reply-To: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> References: <784FBBB0-5863-43EF-B97D-5193E1BD053E@oracle.com> Message-ID: <03B3D5B0-5654-4710-8744-C671DD09C963@oracle.com> Vote: yes igor On Sep 20, 2013, at 5:52 PM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to Membership in the hotspot Group. > > Niclas is an Oracle engineer, currently in the compiler team, and has been working on HotSpot for a year. He is a Commiter for the hsx Project and has contributed more than 19 HotSpot changes already, primarily relating to the server compiler register allocator. > > Votes are due by Friday, October 4, 2013. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Regards, > Roland Westrelin > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From lois.foltan at oracle.com Mon Sep 23 14:17:05 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 23 Sep 2013 17:17:05 -0400 Subject: FR (L) JDK-7195622 (round 2): CheckUnhandledOops has limited usefulness now In-Reply-To: <523B0C44.6090501@oracle.com> References: <523B0C44.6090501@oracle.com> Message-ID: <5240AFD1.7040402@oracle.com> Please review the following updated fix which has removed the CAST_*_OOP macro implementation in favor of two inlined template methods, cast_to_oop() & cast_from_oop(). Webrev: http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.1/ Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & CheckUnhandledOops has limited usefulness now bug links at: https://bugs.openjdk.java.net/browse/JDK-7180556 https://bugs.openjdk.java.net/browse/JDK-7195622 Summary of fix: Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: 1. A review should start at understanding the changes made to oopsHierarchy.hpp a. Addition of a non-volatile copy constructor to address compile time errors reported in JDK-7180556 and also currently by g++ compilers on Linux. b. Addition of member wise assignment operators to handle many instances of [non]volatile to [non]volatile oops within the JVM. Note: Solaris compilers would not allow for the member wise assignment operators of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile assignment operator. So the g++ compilers needed these different flavors of the assignment operator and Solaris did not. d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. g++ specifically complained when trying to pass a volatile "this" pointer. e. Removal of the ambiguous behavior of having overloaded copy constructor and explicit user conversion member functions defined of both integral and void *. All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. 2. Change #1e had the consequence of C++ compilers now generating compile time errors where the practice has been to cast an oop to and from an integral type such as intptr_t. To allow for this practice to continue, when oop is a structure and not a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new inlined template methods, cast_*_oop(), were introduced in oops/oopsHierarchy.hpp 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) by the g++ compilers on Linux and MacOS. This caused several changes to be needed throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). 4. Many instances of an assignment to a volatile oop required a "const_cast" to cast away the volatileness of the lvalue. There is already precedence for this type of change within utilities/taskqueue.hpp. The following comment was in place: // g++ complains if the volatile result of the assignment is // unused, so we cast the volatile away. We cannot cast directly // to void, because gcc treats that as not using the result of the // assignment. However, casting to E& means that we trigger an // unused-value warning. So, we cast the E& to void. 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() member functions was to accommodate the Solaris C++ compiler's complaint about the assignment of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of allowing for all flavors of volatile/non-volatile member wise assignment operators. Per Liden of the GC group did pre-review this specific change with regards to performance implications and was not concerned. 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a fastdebug build, an unresolved symbol occurred. philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed U Hashtable::_seed 0000000000848890 t Hashtable::seed() ... Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. Builds: Solaris (12u1 & 12u3 C++ compilers), MacOS (llvm-g++ & clang++ compilers), Linux (g++ v4.4.3 & g++ v4.7.3), VS2010 Tests: JTREG on MacOS, vm.quick.testlist on LInux, nsk.regression.testlist, nsk.stress.testlist on LInux, JCK vm on Windows Thank you, Lois From alejandro.murillo at oracle.com Tue Sep 24 09:03:23 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 24 Sep 2013 10:03:23 -0600 Subject: Hotspot repos for changes going into jdk7u next (7u60) Message-ID: <5241B7CB.5060101@oracle.com> (1) Hotspot changes intended for the next jdk7u feature release (jdk7u60) should be pushed to (via JPRT, of course): http://hg.openjdk.java.net/hsx/jdk7u/hotspot (2) Bugs should be filed using 7u60 as the version (component is hotspot as usual) (3) http://hg.openjdk.java.net/hsx/jdk7u is a full forest. So if there are features that require pushing tightly coupled hotspot/jdk changes, they can be pushed through this forest and they will be pushed to the master together when hotspot snapshots are taken. Please let me know in advance when these type of changes are coming so I plan the snapshot accordingly. NOTE: if the changes don't need to go together, please push the JDK portions through the jdk7u-dev repos as usual. (4) I will take snapshots of this repo, run PIT (or request a pit waiver), and push to the jdk7u master on a need basis. Mostly depending on the number of changes available. Of course, if there are urgent changes that need to be in the jdk7u master, we will take a snapshot. Just let me know. (5) As usual, users with no access to jprt, please indicate in the "the request for review message" that you will need a sponsor to get the change pushed via JPRT once it has been cleared for pushing. Contact me if no one volunteers Let me know if you have any question Thanks -- Alejandro From vladimir.kozlov at oracle.com Tue Sep 24 14:33:00 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 24 Sep 2013 21:33:00 +0000 Subject: hg: hsx/jdk7u/hotspot: 8021898: Broken JIT compiler optimization for loop unswitching Message-ID: <20130924213307.1E19962AA8@hg.openjdk.java.net> Changeset: 8ada83878f30 Author: kvn Date: 2013-08-16 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/8ada83878f30 8021898: Broken JIT compiler optimization for loop unswitching Summary: fix method clone_projs() to clone all related MachProj nodes. Reviewed-by: roland, adlertz ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/utilities/vmError.cpp From vladimir.kozlov at oracle.com Tue Sep 24 21:24:46 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 25 Sep 2013 04:24:46 +0000 Subject: hg: hsx/jdk7u/hotspot: 8022585: VM crashes when ran with -XX:+PrintInlining Message-ID: <20130925042451.536C662AB4@hg.openjdk.java.net> Changeset: 68ae51f39b18 Author: kvn Date: 2013-09-24 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/68ae51f39b18 8022585: VM crashes when ran with -XX:+PrintInlining Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method. Reviewed-by: twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/print/PrintInlining.java From vladimir.kozlov at oracle.com Wed Sep 25 00:14:56 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 25 Sep 2013 07:14:56 +0000 Subject: hg: hsx/jdk7u/hotspot: 8023472: C2 optimization breaks with G1 Message-ID: <20130925071501.B99FC62AB9@hg.openjdk.java.net> Changeset: 55221e76f69e Author: kvn Date: 2013-08-23 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/55221e76f69e 8023472: C2 optimization breaks with G1 Summary: set control edge for previous value load in G1 pre-barrier Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp + test/compiler/gcbarriers/G1CrashTest.java From ivan at azulsystems.com Wed Sep 25 05:12:09 2013 From: ivan at azulsystems.com (Ivan Krylov) Date: Wed, 25 Sep 2013 12:12:09 +0000 Subject: Visual Studio project creator Message-ID: Folks, I am not sure who is maintaining the visual studio project generator these days. It used to be the Runtime team in the past including myself. I just created a jvm project for Visual Studio out of hsx 24 (7u40) using hotspot\make\windows\create and I am seeing errors. Out of the batch build all job I get this: ========== Rebuild All: 3 succeeded, 9 failed, 0 skipped ========== I see several errors 1) the definitions in globals.hpp are guarded with #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) which is not true for core targets ClCompile: java.cpp c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/globals.hpp(170): error C2370: 'pd_InlineSmallCode' : redefinition; different storage class c:\dev\jdk7u40-vanilla\hotspot\src\cpu\x86\vm\globals_x86.hpp(56) : see declaration of 'pd_InlineSmallCode' 2) Missing an include directory for the generated jvmtifiles ClCompile: java.cpp c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/os.hpp(28): fatal error C1083: Cannot open include file: 'jvmtifiles/jvmti.h': No such file or directory 3) I also get the following warning: jni.obj : warning LNK4197: export 'JNI_GetDefaultJavaVMInitArgs' specified multiple times; using first specification jni.obj : warning LNK4197: export 'JNI_GetCreatedJavaVMs' specified multiple times; using first specification jni.obj : warning LNK4197: export 'JNI_CreateJavaVM' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'jio_vsnprintf' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'jio_snprintf' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'jio_vfprintf' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'jio_printf' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'JVM_GetVersionInfo' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'jio_fprintf' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'JVM_InitAgentProperties' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'JVM_GetThreadStateValues' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'JVM_FindClassFromBootLoader' specified multiple times; using first specification jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified multiple times; using first specification Creating library c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.lib and object c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.exp jvm.vcxproj -> c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.dll PostBuildEvent: Description: Building hotspot.exe... 1 and 2 should be easy to fix, 3 - I am not sure. Since I am looking at u40 could this have been fixed since then? Thanks, Ivan From francis.andre.kampbell at orange.fr Wed Sep 25 10:52:19 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Wed, 25 Sep 2013 19:52:19 +0200 Subject: JDK7u, hotspot, CC_INTERP, and COBOL Message-ID: <524322D3.4050000@orange.fr> Hi On WXP with VS2010 and the http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/ repository, I successfully build and ran the debug version of hotspot in compiler1 directory. fine Next, I tried to get working the bytecode cppInterpreter instead of the template based interpreter adding the CC_INTERP=true preprocessor define, but I got several compile errors -- see below -- By looking at the Wiki and the OpenJDK website, I discovered that the cppInterpreter was no more maintained. So I am wondering why the cppInterpreter is not anymore maintained and would like to understand if this decision is definitive or not, because it seems to me that there are very few errors. (see above) and that, IMHO, a somewhat small effort should be made to fix the cppInterpreter (but it could be totally wrong). I need the cppInterpreter to make a proposal to the MLVM project to slightly change the JVM spec for all xALOAD and xASTORE bytecodes for a specific class version number for an efficient support of a _COBOL __runtime_. Regards Francis cppInterpreter_x86.cpp 1> frame_x86.cpp 1> interpreter_x86_32.cpp 1> interp_masm_x86_32.cpp 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039: 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065: 'interpreter_frame_sender_sp_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039: 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065: 'interpreter_frame_last_sp_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039: 'interpreter_frame_method_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065: 'interpreter_frame_method_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039: 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065: 'interpreter_frame_mdx_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039: 'interpreter_frame_cache_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065: 'interpreter_frame_cache_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039: 'interpreter_frame_locals_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065: 'interpreter_frame_locals_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039: 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065: 'interpreter_frame_bcx_offset' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039: 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065: 'interpreter_frame_initial_sp_offset' : identificateur non d?clar? 1> sharedRuntime_x86_32.cpp 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220: avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146: op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039: 'increment_mask_and_jump' : n'est pas membre de 'InterpreterMacroAssembler' 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur de syntaxe : identificateur 'Condition' 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl' : identificateur introuvable 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861: 'incrementl' : identificateur introuvable 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl' : identificateur introuvable 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl' : identificateur introuvable 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' : identificateur introuvable 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039: 'empty_expression_stack' : n'est pas membre de 'InterpreterMacroAssembler' 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039: 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler' 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: 'method_handle' : n'est pas membre de 'Interpreter' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143) : voir la d?claration de 'Interpreter' 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065: 'method_handle' : identificateur non d?clar? 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051: l'expression associ?e ? case n'est pas une constante 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: 'generate_method_handle_entry' : n'est pas membre de 'InterpreterGenerator' 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37) : voir la d?claration de 'InterpreterGenerator' 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le terme ne correspond pas ? une fonction qui prend 0 arguments 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220: avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146: op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? ========== G?n?ration : 0 a r?ussi, 1 a ?chou?, 0 mis ? jour, 0 a ?t? ignor? ========== From christian.thalinger at oracle.com Wed Sep 25 12:06:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Sep 2013 12:06:50 -0700 Subject: FR (L) JDK-7195622 (round 2): CheckUnhandledOops has limited usefulness now In-Reply-To: <5240AFD1.7040402@oracle.com> References: <523B0C44.6090501@oracle.com> <5240AFD1.7040402@oracle.com> Message-ID: <9797D061-6B27-4B0D-BECE-6E49C1FCB4EE@oracle.com> This looks good. Thank you for changing it to template methods instead of using macros. On Sep 23, 2013, at 2:17 PM, Lois Foltan wrote: > > Please review the following updated fix which has removed the CAST_*_OOP macro > implementation in favor of two inlined template methods, cast_to_oop() & cast_from_oop(). > > Webrev: > http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.1/ > > Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & > CheckUnhandledOops has limited usefulness now bug links at: > > https://bugs.openjdk.java.net/browse/JDK-7180556 > https://bugs.openjdk.java.net/browse/JDK-7195622 > > Summary of fix: > > Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: > > 1. A review should start at understanding the changes made to oopsHierarchy.hpp > a. Addition of a non-volatile copy constructor to address compile time errors > reported in JDK-7180556 and also currently by g++ compilers on Linux. > b. Addition of member wise assignment operators to handle many instances > of [non]volatile to [non]volatile oops within the JVM. > Note: Solaris compilers would not allow for the member wise assignment operators > of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, > Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile > assignment operator. So the g++ compilers needed these different flavors > of the assignment operator and Solaris did not. > d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. > g++ specifically complained when trying to pass a volatile "this" pointer. > e. Removal of the ambiguous behavior of having overloaded copy constructor and > explicit user conversion member functions defined of both integral and void *. > All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. > > 2. Change #1e had the consequence of C++ compilers now generating compile time > errors where the practice has been to cast an oop to and from an integral type such > as intptr_t. To allow for this practice to continue, when oop is a structure and not > a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new > inlined template methods, cast_*_oop(), were introduced in oops/oopsHierarchy.hpp > > 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) > by the g++ compilers on Linux and MacOS. This caused several changes to be needed > throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). > > 4. Many instances of an assignment to a volatile oop required a "const_cast" to > cast away the volatileness of the lvalue. There is already precedence for this > type of change within utilities/taskqueue.hpp. The following comment was in place: > > // g++ complains if the volatile result of the assignment is > // unused, so we cast the volatile away. We cannot cast > directly > // to void, because gcc treats that as not using the result > of the > // assignment. However, casting to E& means that we trigger an > // unused-value warning. So, we cast the E& to void. > > 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() > member functions was to accommodate the Solaris C++ compiler's complaint about the assignment > of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated > with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of > allowing for all flavors of volatile/non-volatile member wise assignment operators. > Per Liden of the GC group did pre-review this specific change with regards to performance > implications and was not concerned. > > 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation > of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a > fastdebug build, an unresolved symbol occurred. > philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed > U Hashtable::_seed > 0000000000848890 t Hashtable::seed() > ... > > Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. > > Builds: > Solaris (12u1 & 12u3 C++ compilers), > MacOS (llvm-g++ & clang++ compilers), > Linux (g++ v4.4.3 & g++ v4.7.3), > VS2010 > > Tests: > JTREG on MacOS, > vm.quick.testlist on LInux, > nsk.regression.testlist, nsk.stress.testlist on LInux, > JCK vm on Windows > > Thank you, Lois > > > > > > > > From lois.foltan at oracle.com Wed Sep 25 13:14:36 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 25 Sep 2013 16:14:36 -0400 Subject: FR (L) JDK-7195622 (round 2): CheckUnhandledOops has limited usefulness now In-Reply-To: <9797D061-6B27-4B0D-BECE-6E49C1FCB4EE@oracle.com> References: <523B0C44.6090501@oracle.com> <5240AFD1.7040402@oracle.com> <9797D061-6B27-4B0D-BECE-6E49C1FCB4EE@oracle.com> Message-ID: <5243442C.4020801@oracle.com> On 9/25/2013 3:06 PM, Christian Thalinger wrote: > This looks good. Thank you for changing it to template methods instead of using macros. Great, thank you for taking the time to look at this given your week at JavaOne. Lois > > On Sep 23, 2013, at 2:17 PM, Lois Foltan wrote: > >> Please review the following updated fix which has removed the CAST_*_OOP macro >> implementation in favor of two inlined template methods, cast_to_oop() & cast_from_oop(). >> >> Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.1/ >> >> Bug: JDK8 b44 hotspot:src/share/vm/oops/klass.hpp: Error:Initializing const volatile oop& requires ... & >> CheckUnhandledOops has limited usefulness now bug links at: >> >> https://bugs.openjdk.java.net/browse/JDK-7180556 >> https://bugs.openjdk.java.net/browse/JDK-7195622 >> >> Summary of fix: >> >> Update the C++ oop structure definition in oopsHierarchy.hpp to solve several problems with the current definition when compiled with various C++ compilers across supported platforms. These changes initially address the problem reported in JDK-7180556 and continue with additional improvements to allow CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds on all platforms as suggested in JDK-7195622. Several notes concerning this fix: >> >> 1. A review should start at understanding the changes made to oopsHierarchy.hpp >> a. Addition of a non-volatile copy constructor to address compile time errors >> reported in JDK-7180556 and also currently by g++ compilers on Linux. >> b. Addition of member wise assignment operators to handle many instances >> of [non]volatile to [non]volatile oops within the JVM. >> Note: Solaris compilers would not allow for the member wise assignment operators >> of every flavor of non-volatile to volatile and vice versa. However, unlike g++ compilers, >> Solaris compilers had no issue passing a volatile "this" pointer to a non-volatile >> assignment operator. So the g++ compilers needed these different flavors >> of the assignment operator and Solaris did not. >> d. For similar reasons as 1b, addition of a volatile explicit conversion from oop -> void *. >> g++ specifically complained when trying to pass a volatile "this" pointer. >> e. Removal of the ambiguous behavior of having overloaded copy constructor and >> explicit user conversion member functions defined of both integral and void *. >> All C++ compilers, except Solaris, issue a compile time error concerning this ambiguity. >> >> 2. Change #1e had the consequence of C++ compilers now generating compile time >> errors where the practice has been to cast an oop to and from an integral type such >> as intptr_t. To allow for this practice to continue, when oop is a structure and not >> a OopDesc *, as is the case when CHECK_UNHANDLED_OOPS is defined, two new >> inlined template methods, cast_*_oop(), were introduced in oops/oopsHierarchy.hpp >> >> 3. Due to the change in #1a & #1b, the oop structure in no longer considered a POD (plain old data) >> by the g++ compilers on Linux and MacOS. This caused several changes to be needed >> throughout the JVM to add an (void *) cast of an oop when invoking print_cr(). >> >> 4. Many instances of an assignment to a volatile oop required a "const_cast" to >> cast away the volatileness of the lvalue. There is already precedence for this >> type of change within utilities/taskqueue.hpp. The following comment was in place: >> >> // g++ complains if the volatile result of the assignment is >> // unused, so we cast the volatile away. We cannot cast >> directly >> // to void, because gcc treats that as not using the result >> of the >> // assignment. However, casting to E& means that we trigger an >> // unused-value warning. So, we cast the E& to void. >> >> 5. The addition of the volatile keyword to the GenericTaskQueue's pop_local() & pop_global() >> member functions was to accommodate the Solaris C++ compiler's complaint about the assignment >> of the volatile elements of the private member data _elems when GenericTaskQueue is instantiated >> with a non-volatile oop. Line #723 in pop_local(). This was a result of #1b, Solaris' lack of >> allowing for all flavors of volatile/non-volatile member wise assignment operators. >> Per Liden of the GC group did pre-review this specific change with regards to performance >> implications and was not concerned. >> >> 6. In utilities/hashtable.cpp, required CHECK_UNHANDLED_OOPS conditional for the instantiation >> of "template class Hashtable". With CHECK_UHANDLED_OOPS specified for a >> fastdebug build, an unresolved symbol occurred. >> philli:% nm --demangle build//linux_amd64_compiler2/fastdebug/libjvm.so | grep Hashtable | grep seed >> U Hashtable::_seed >> 0000000000848890 t Hashtable::seed() >> ... >> >> Making these improvements allows for CHECK_UNHANDLED_OOPS to be defined in all fastdebug builds across the supported platforms. >> >> Builds: >> Solaris (12u1 & 12u3 C++ compilers), >> MacOS (llvm-g++ & clang++ compilers), >> Linux (g++ v4.4.3 & g++ v4.7.3), >> VS2010 >> >> Tests: >> JTREG on MacOS, >> vm.quick.testlist on LInux, >> nsk.regression.testlist, nsk.stress.testlist on LInux, >> JCK vm on Windows >> >> Thank you, Lois >> >> >> >> >> >> >> >> From christian.thalinger at oracle.com Wed Sep 25 14:17:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Sep 2013 14:17:13 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> <523B8E01.9070809@oracle.com> Message-ID: <3F42DC31-25F5-4441-B04B-342EA234EA1E@oracle.com> Oh well. It turned out that SunStudio cannot handle strings properly in the static table. So I chose another approach which actually uses less memory: for develop and notproduct flags define both a const variable and a static variable with CONST_ as a prefix. The address of the latter is then used in the flags table. No need for an additional _value field. With that the binary size increase is: linux_i486_compiler2: 24k linux_i486_minimal1: 17k I hope this is the last iteration: http://cr.openjdk.java.net/~twisti/8024545/webrev/ The gist of this iteration is at the bottom of this page: http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html On Sep 19, 2013, at 6:34 PM, Christian Thalinger wrote: > Thank you, again, Vladimir. > > On Sep 19, 2013, at 4:51 PM, Vladimir Kozlov wrote: > >> Good. >> >> Vladimir >> >> On 9/19/13 4:08 PM, Christian Thalinger wrote: >>> JPRT found some problems. Apparently something does #define C2 'E' on Solaris so I had to prefix all kind flags with KIND_: >>> >>> + // flag kind >>> + KIND_PRODUCT = 1 << 4, >>> + KIND_MANAGEABLE = 1 << 5, >>> + KIND_DIAGNOSTIC = 1 << 6, >>> + KIND_EXPERIMENTAL = 1 << 7, >>> + KIND_NOT_PRODUCT = 1 << 8, >>> + KIND_DEVELOP = 1 << 9, >>> + KIND_PLATFORM_DEPENDENT = 1 << 10, >>> + KIND_READ_WRITE = 1 << 11, >>> + KIND_C1 = 1 << 12, >>> + KIND_C2 = 1 << 13, >>> + KIND_ARCH = 1 << 14, >>> + KIND_SHARK = 1 << 15, >>> + KIND_LP64_PRODUCT = 1 << 16, >>> + KIND_COMMERCIAL = 1 << 17, >>> >>> Two other problems found by Visual Studio were a bool return: >>> >>> + bool Flag::get_bool() const { >>> + if (is_constant_in_binary()) { >>> + return _value != 0; >>> + } else { >>> + return *((bool*) _addr); >>> + } >>> + } >>> >>> and the size_t changes at the bottom of this file: >>> >>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>> >>> Everything else (except the renames) are the same. I tried to create an incremental webrev but I failed. Sorry. >>> >>> On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: >>> >>>> >>>> On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: >>>> >>>>> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>>>>> >>>>>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Christian, >>>>>>> >>>>>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>>>>> >>>>>> Yes, good point. >>>>>> >>>>>>> >>>>>>> It would be nice enumerate flag's type and use int instead of strings: >>>>>>> >>>>>>> enum { >>>>>>> bool_flag = 1, >>>>>>> intx_flag = 2, >>>>>>> >>>>>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>>>>> >>>>>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >>>>> >>>>> Do it in separate changes after you push this. >>>>> And if you remove _type field later you don't need to move _flags now. >>>>> So you can push your current changes as it is. They are good. >>>> >>>> Thank you, Vladimir. -- Chris >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>>>>> >>>>>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>>>>> >>>>>>>>> + if (is_constant_in_binary()) { >>>>>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>>>>> >>>>>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>>>>> >>>>>>>> Good point. I made that change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>>>>> >>>>>>>>> >>>>>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>>>>> >>>>>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>>>>> >>>>>>>>> >>>>>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>>>>> >>>>>>>> The 32-bit product build also contains the server compiler. >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>>>>> >>>>>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>>>>> Reviewed-by: >>>>>>>>>> >>>>>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>>>>> >>>>>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>>>>> >>>>>>>>>> Before: >>>>>>>>>> >>>>>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>>>>> Attaching to process 9399, please wait... >>>>>>>>>> hsdb> flags -nd >>>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>>> UseCompressedOops = true 5 >>>>>>>>>> UseParallelGC = true 5 >>>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>>> Couldn't find flag: InlineMathNatives >>>>>>>>>> >>>>>>>>>> After: >>>>>>>>>> >>>>>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>>>>> Attaching to process 3726, please wait... >>>>>>>>>> hsdb> flags -nd >>>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>>> UseCompressedOops = true 5 >>>>>>>>>> UseParallelGC = true 5 >>>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>>> InlineMathNatives = true 0 >>>>>>>>>> >>>>>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>>>>> >>>>>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>>>>> >>>>>>>>>> The output for product builds is unchanged. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Wed Sep 25 14:49:18 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 25 Sep 2013 21:49:18 +0000 Subject: hg: hsx/jdk7u/hotspot: 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag Message-ID: <20130925214924.3C3B962AF3@hg.openjdk.java.net> Changeset: 1a8e36934dfe Author: kvn Date: 2013-08-14 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1a8e36934dfe 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag. Reviewed-by: roland ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp From zhengyu.gu at oracle.com Wed Sep 25 14:54:47 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 25 Sep 2013 21:54:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 19 new changesets Message-ID: <20130925215528.A95D962AF4@hg.openjdk.java.net> Changeset: 63147986a428 Author: dcubed Date: 2013-09-18 07:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/63147986a428 8019835: Strings interned in different threads equal but does not == Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants. Reviewed-by: rdurbin, sspitsyn, coleenp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: dfae98867ee8 Author: dholmes Date: 2013-09-18 20:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dfae98867ee8 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps Reviewed-by: alanb, chegar, dholmes, ksrini Contributed-by: Mike Duigou ! src/share/vm/runtime/arguments.cpp Changeset: c1d7040a1183 Author: sgabdura Date: 2013-09-18 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c1d7040a1183 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor() Reviewed-by: dcubed, dsamersoff ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 8c84f04ff977 Author: kevinw Date: 2013-09-18 19:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c84f04ff977 Merge Changeset: 6eb908998b32 Author: kevinw Date: 2013-09-19 08:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6eb908998b32 Merge Changeset: 9ed97b511b26 Author: hseigel Date: 2013-09-19 11:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9ed97b511b26 8024517: runtime/CDSCompressedKPtrs/XShareAuto.java failed with RuntimeException Summary: Make sure CDS is off by default when running server compiler. Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/arguments.cpp ! test/runtime/CDSCompressedKPtrs/XShareAuto.java Changeset: 4f9a42c33738 Author: coleenp Date: 2013-09-20 09:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4f9a42c33738 8022887: Assertion hit while using class and redefining it with RedefineClasses simultaneously Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: dcubed, sspitsyn ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp Changeset: f201713502e0 Author: coleenp Date: 2013-09-20 09:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f201713502e0 Merge Changeset: 1b03bed31241 Author: allwin Date: 2013-09-17 17:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b03bed31241 7196151: ParserTest SEGv on solaris Reviewed-by: sla, coleenp, ctornqvi, dsamersoff ! src/share/vm/services/diagnosticArgument.cpp Changeset: e5a25e4ae509 Author: mgerdin Date: 2013-09-20 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e5a25e4ae509 Merge Changeset: 7c29904fdfa2 Author: coleenp Date: 2013-09-20 18:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c29904fdfa2 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solaris 64 Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found. Reviewed-by: hseigel, dcubed, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: df03413ad1a9 Author: coleenp Date: 2013-09-21 01:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df03413ad1a9 Merge Changeset: 0f37d1badced Author: dcubed Date: 2013-09-20 12:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f37d1badced Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a7609ec351d6 Author: dcubed Date: 2013-09-20 18:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a7609ec351d6 Merge ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 8ddc26f62476 Author: sla Date: 2013-09-22 06:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8ddc26f62476 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" Reviewed-by: sla, dsamersoff Contributed-by: Yasumasa Suenaga ! src/share/vm/services/attachListener.cpp Changeset: 1f42d3ec1759 Author: dsamersoff Date: 2013-09-22 18:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f42d3ec1759 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not Summary: replace PT_LOAD segment with library segment when necessary Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ae2edb3df7fb Author: dsamersoff Date: 2013-09-22 18:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ae2edb3df7fb Merge Changeset: 084b21cd0228 Author: iklam Date: 2013-09-23 08:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/084b21cd0228 8025088: Missing cases for JVM_CONSTANT_MethodHandleInError cause crash if debugger steps into error-tagged method handle Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: e8a0010ba69e Author: zgu Date: 2013-09-25 13:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8a0010ba69e Merge From chandanpr at gmail.com Wed Sep 25 21:22:56 2013 From: chandanpr at gmail.com (Chandan PR) Date: Thu, 26 Sep 2013 09:52:56 +0530 Subject: Fast Throw - Cached Exceptions Message-ID: Hi , I was trying to understand returning cached instance of Exception during fast throw. After a bit of debugging in the hotspot VM code, was able to understand most of it. But lost a bit for NullPointerException case. in hotspot/src/share/vm/opto/graphKit.cpp.null_check_common in the case of T_OBJECT: we have the below code // See if mixing in the NULL pointer changes type. // If so, then the NULL pointer was not allowed in the original // type. In other words, "value" was not-null. if (t->meet(TypePtr::NULL_PTR) != t) { // same as: if (!TypePtr::NULL_PTR->higher_equal(t)) ... explicit_null_checks_elided++; return value; // Elided null check quickly! } For some reference types like String, StringBuffer mixing results in NUL pointer for some others like Object or Interface reference types, the mixing changes the NULL pointer type. Was trying to understand the concept/logic and relation to pointer types regarding this. But lost a bit. My Sample program is below: public class FastThrowDemo { public static void main(String[] args) { // StringBuffer obj = null; // String obj = null; // Object obj = null; Serializable obj = null; for (int i = 0; i < 10_000_00; i++) { try { obj.toString(); } catch (Exception e) { } } try { obj.toString(); } catch (Exception e) { int length = e.getStackTrace().length; if (length == 0) { System.err.println("No Stack Trace"); } else { System.out.println("Stack Trace length is " + length); } } } } Any further information or pointers for further reading would be helpful. -- Thanks and Regards, Chandan.P.R 9945501674 From niclas.adlertz at oracle.com Thu Sep 26 03:54:46 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Thu, 26 Sep 2013 10:54:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130926105452.834B062B08@hg.openjdk.java.net> Changeset: 891687731b59 Author: anoll Date: 2013-09-24 15:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/891687731b59 7009641: Don't fail VM when CodeCache is full Summary: Allocation in the code cache returns NULL instead of failing the entire VM Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 1b64d46620a3 Author: kvn Date: 2013-09-24 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b64d46620a3 8022585: VM crashes when ran with -XX:+PrintInlining Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method. Reviewed-by: twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/print/PrintInlining.java Changeset: f637d4dc21bb Author: adlertz Date: 2013-09-26 08:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f637d4dc21bb Merge From bertrand.delsart at oracle.com Thu Sep 26 06:28:49 2013 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Thu, 26 Sep 2013 13:28:49 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130926132903.C74BE62B0B@hg.openjdk.java.net> Changeset: 586fa1919a89 Author: bpittore Date: 2013-09-20 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/586fa1919a89 8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true' Reviewed-by: kvn, twisti, dholmes ! src/share/vm/runtime/vm_version.hpp Changeset: 504d8f519adf Author: jiangli Date: 2013-09-20 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/504d8f519adf Merge Changeset: d682c6e24fe3 Author: bdelsart Date: 2013-09-26 01:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d682c6e24fe3 Merge Changeset: 60a2d625db36 Author: bdelsart Date: 2013-09-26 04:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/60a2d625db36 Merge From vladimir.kozlov at oracle.com Thu Sep 26 09:26:58 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 26 Sep 2013 09:26:58 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <3F42DC31-25F5-4441-B04B-342EA234EA1E@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> <523B8E01.9070809@oracle.com> <3F42DC31-25F5-4441-B04B-342EA234EA1E@oracle.com> Message-ID: <52446052.6050306@oracle.com> Christian, It will make reviewers life much easier if you start using webrev versions instead of always replacing one. It is last time I will review such changes without version. It is passed JPRT so I hope it is final iteration. It looks fine. Vladimir On 9/25/13 2:17 PM, Christian Thalinger wrote: > Oh well. It turned out that SunStudio cannot handle strings properly in the static table. So I chose another approach which actually uses less memory: for develop and notproduct flags define both a const variable and a static variable with CONST_ as a prefix. The address of the latter is then used in the flags table. No need for an additional _value field. > > With that the binary size increase is: > > linux_i486_compiler2: 24k > linux_i486_minimal1: 17k > > I hope this is the last iteration: > > http://cr.openjdk.java.net/~twisti/8024545/webrev/ > > The gist of this iteration is at the bottom of this page: > > http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html > > On Sep 19, 2013, at 6:34 PM, Christian Thalinger wrote: > >> Thank you, again, Vladimir. >> >> On Sep 19, 2013, at 4:51 PM, Vladimir Kozlov wrote: >> >>> Good. >>> >>> Vladimir >>> >>> On 9/19/13 4:08 PM, Christian Thalinger wrote: >>>> JPRT found some problems. Apparently something does #define C2 'E' on Solaris so I had to prefix all kind flags with KIND_: >>>> >>>> + // flag kind >>>> + KIND_PRODUCT = 1 << 4, >>>> + KIND_MANAGEABLE = 1 << 5, >>>> + KIND_DIAGNOSTIC = 1 << 6, >>>> + KIND_EXPERIMENTAL = 1 << 7, >>>> + KIND_NOT_PRODUCT = 1 << 8, >>>> + KIND_DEVELOP = 1 << 9, >>>> + KIND_PLATFORM_DEPENDENT = 1 << 10, >>>> + KIND_READ_WRITE = 1 << 11, >>>> + KIND_C1 = 1 << 12, >>>> + KIND_C2 = 1 << 13, >>>> + KIND_ARCH = 1 << 14, >>>> + KIND_SHARK = 1 << 15, >>>> + KIND_LP64_PRODUCT = 1 << 16, >>>> + KIND_COMMERCIAL = 1 << 17, >>>> >>>> Two other problems found by Visual Studio were a bool return: >>>> >>>> + bool Flag::get_bool() const { >>>> + if (is_constant_in_binary()) { >>>> + return _value != 0; >>>> + } else { >>>> + return *((bool*) _addr); >>>> + } >>>> + } >>>> >>>> and the size_t changes at the bottom of this file: >>>> >>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>> >>>> Everything else (except the renames) are the same. I tried to create an incremental webrev but I failed. Sorry. >>>> >>>> On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>>>>>> >>>>>>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Christian, >>>>>>>> >>>>>>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>>>>>> >>>>>>> Yes, good point. >>>>>>> >>>>>>>> >>>>>>>> It would be nice enumerate flag's type and use int instead of strings: >>>>>>>> >>>>>>>> enum { >>>>>>>> bool_flag = 1, >>>>>>>> intx_flag = 2, >>>>>>>> >>>>>>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>>>>>> >>>>>>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >>>>>> >>>>>> Do it in separate changes after you push this. >>>>>> And if you remove _type field later you don't need to move _flags now. >>>>>> So you can push your current changes as it is. They are good. >>>>> >>>>> Thank you, Vladimir. -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>>> Hi Chris, >>>>>>>>>> >>>>>>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>>>>>> >>>>>>>>>> + if (is_constant_in_binary()) { >>>>>>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>>>>>> >>>>>>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>>>>>> >>>>>>>>> Good point. I made that change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>>>>>> >>>>>>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>>>>>> >>>>>>>>> The 32-bit product build also contains the server compiler. >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>>>>>> >>>>>>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> >>>>>>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>>>>>> >>>>>>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>>>>>> >>>>>>>>>>> Before: >>>>>>>>>>> >>>>>>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>>>>>> Attaching to process 9399, please wait... >>>>>>>>>>> hsdb> flags -nd >>>>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>>>> UseCompressedOops = true 5 >>>>>>>>>>> UseParallelGC = true 5 >>>>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>>>> Couldn't find flag: InlineMathNatives >>>>>>>>>>> >>>>>>>>>>> After: >>>>>>>>>>> >>>>>>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>>>>>> Attaching to process 3726, please wait... >>>>>>>>>>> hsdb> flags -nd >>>>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>>>> UseCompressedOops = true 5 >>>>>>>>>>> UseParallelGC = true 5 >>>>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>>>> InlineMathNatives = true 0 >>>>>>>>>>> >>>>>>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>>>>>> >>>>>>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>>>>>> >>>>>>>>>>> The output for product builds is unchanged. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From christian.thalinger at oracle.com Thu Sep 26 11:00:49 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 26 Sep 2013 11:00:49 -0700 Subject: RFR (L): 8024545: make develop and notproduct flag values available in product builds In-Reply-To: <52446052.6050306@oracle.com> References: <5103309F-F0A0-4253-A53E-708CFD3955AB@oracle.com> <52310C27.2060107@oracle.com> <52324E89.9060006@oracle.com> <52325B31.5070604@oracle.com> <0785BD0A-5A4F-4ED6-8DAF-D90C74D55628@oracle.com> <5CA11A3E-086C-42E1-9B22-3B525877ECCE@oracle.com> <523B8E01.9070809@oracle.com> <3F42DC31-25F5-4441-B04B-342EA234EA1E@oracle.com> <52446052.6050306@oracle.com> Message-ID: On Sep 26, 2013, at 9:26 AM, Vladimir Kozlov wrote: > Christian, > > It will make reviewers life much easier if you start using webrev versions instead of always replacing one. It is last time I will review such changes without version. Alright. You convinced me :-) > > It is passed JPRT so I hope it is final iteration. It looks fine. Thank you. > > Vladimir > > On 9/25/13 2:17 PM, Christian Thalinger wrote: >> Oh well. It turned out that SunStudio cannot handle strings properly in the static table. So I chose another approach which actually uses less memory: for develop and notproduct flags define both a const variable and a static variable with CONST_ as a prefix. The address of the latter is then used in the flags table. No need for an additional _value field. >> >> With that the binary size increase is: >> >> linux_i486_compiler2: 24k >> linux_i486_minimal1: 17k >> >> I hope this is the last iteration: >> >> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >> >> The gist of this iteration is at the bottom of this page: >> >> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html >> >> On Sep 19, 2013, at 6:34 PM, Christian Thalinger wrote: >> >>> Thank you, again, Vladimir. >>> >>> On Sep 19, 2013, at 4:51 PM, Vladimir Kozlov wrote: >>> >>>> Good. >>>> >>>> Vladimir >>>> >>>> On 9/19/13 4:08 PM, Christian Thalinger wrote: >>>>> JPRT found some problems. Apparently something does #define C2 'E' on Solaris so I had to prefix all kind flags with KIND_: >>>>> >>>>> + // flag kind >>>>> + KIND_PRODUCT = 1 << 4, >>>>> + KIND_MANAGEABLE = 1 << 5, >>>>> + KIND_DIAGNOSTIC = 1 << 6, >>>>> + KIND_EXPERIMENTAL = 1 << 7, >>>>> + KIND_NOT_PRODUCT = 1 << 8, >>>>> + KIND_DEVELOP = 1 << 9, >>>>> + KIND_PLATFORM_DEPENDENT = 1 << 10, >>>>> + KIND_READ_WRITE = 1 << 11, >>>>> + KIND_C1 = 1 << 12, >>>>> + KIND_C2 = 1 << 13, >>>>> + KIND_ARCH = 1 << 14, >>>>> + KIND_SHARK = 1 << 15, >>>>> + KIND_LP64_PRODUCT = 1 << 16, >>>>> + KIND_COMMERCIAL = 1 << 17, >>>>> >>>>> Two other problems found by Visual Studio were a bool return: >>>>> >>>>> + bool Flag::get_bool() const { >>>>> + if (is_constant_in_binary()) { >>>>> + return _value != 0; >>>>> + } else { >>>>> + return *((bool*) _addr); >>>>> + } >>>>> + } >>>>> >>>>> and the size_t changes at the bottom of this file: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>> >>>>> Everything else (except the renames) are the same. I tried to create an incremental webrev but I failed. Sorry. >>>>> >>>>> On Sep 12, 2013, at 6:00 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Sep 12, 2013, at 5:24 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 9/12/13 5:11 PM, Christian Thalinger wrote: >>>>>>>> >>>>>>>> On Sep 12, 2013, at 4:30 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Christian, >>>>>>>>> >>>>>>>>> Can you put _flags first to avoid padding between _addr and _value in 32-bit VM? >>>>>>>> >>>>>>>> Yes, good point. >>>>>>>> >>>>>>>>> >>>>>>>>> It would be nice enumerate flag's type and use int instead of strings: >>>>>>>>> >>>>>>>>> enum { >>>>>>>>> bool_flag = 1, >>>>>>>>> intx_flag = 2, >>>>>>>>> >>>>>>>>> + #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { type##_flag, XSTR(name), &name, VALUE(value), NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, >>>>>>>> >>>>>>>> I was thinking of putting the type into the flags, too. That would save another pointer word. Should I give it a shot in this change or a separate one? >>>>>>> >>>>>>> Do it in separate changes after you push this. >>>>>>> And if you remove _type field later you don't need to move _flags now. >>>>>>> So you can push your current changes as it is. They are good. >>>>>> >>>>>> Thank you, Vladimir. -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/12/13 9:58 AM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>> On Sep 11, 2013, at 5:34 PM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> Hi Chris, >>>>>>>>>>> >>>>>>>>>>> There seems to be an awful lot "infrastructure" work needed to make something that sounds simple happen. :( All the changes to the scoping and the set/get methods tends to obscure the core change. My only suggestion here is that the "set" methods could perhaps factor this: >>>>>>>>>>> >>>>>>>>>>> + if (is_constant_in_binary()) { >>>>>>>>>>> + fatal(err_msg("flag is constant: %s", _name)); >>>>>>>>>>> >>>>>>>>>>> into a check_writable() method so that it isn't duplicated so much. >>>>>>>>>> >>>>>>>>>> Good point. I made that change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.cpp.udiff.html >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I also wonder whether a ConstFlag sub/superclass would simplify this at all? >>>>>>>>>> >>>>>>>>>> Maybe it would but then we need more infrastructure to read the additional entries. Might be a wash. SA only knows about offsets in structs and the flags array is statically defined. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That aside I'm curious why the minimal VM size change is only 22K when client is 32K? >>>>>>>>>> >>>>>>>>>> The 32-bit product build also contains the server compiler. >>>>>>>>>> >>>>>>>>>> -- Chris >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 11/09/2013 10:56 AM, Christian Thalinger wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8024545/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> 8024545: make develop and notproduct flag values available in product builds >>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>> >>>>>>>>>>>> Right now the internal flag table only contains flags which are defined in a product build. This does not include develop and notproduct flags. Sometimes it is useful to have access to these values for post-mortem core file analysis or to read these values for compiler settings for a Java-based compiler. >>>>>>>>>>>> >>>>>>>>>>>> This change enables develop and notproduct flag values to be read by the serviceability agent. The binary size is increased by 42k for a 64-bit product build and by 32k for a 32-bit product build. >>>>>>>>>>>> >>>>>>>>>>>> Before: >>>>>>>>>>>> >>>>>>>>>>>> $ java -cp /java/re/jdk/8/latest/binaries/linux-x64/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 9399 >>>>>>>>>>>> Attaching to process 9399, please wait... >>>>>>>>>>>> hsdb> flags -nd >>>>>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>>>>> UseCompressedOops = true 5 >>>>>>>>>>>> UseParallelGC = true 5 >>>>>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>>>>> Couldn't find flag: InlineMathNatives >>>>>>>>>>>> >>>>>>>>>>>> After: >>>>>>>>>>>> >>>>>>>>>>>> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB 3726 >>>>>>>>>>>> Attaching to process 3726, please wait... >>>>>>>>>>>> hsdb> flags -nd >>>>>>>>>>>> InitialHeapSize = 495006528 5 >>>>>>>>>>>> MaxHeapSize = 7920943104 5 >>>>>>>>>>>> UseCompressedKlassPointers = true 5 >>>>>>>>>>>> UseCompressedOops = true 5 >>>>>>>>>>>> UseParallelGC = true 5 >>>>>>>>>>>> hsdb> flags InlineMathNatives >>>>>>>>>>>> InlineMathNatives = true 0 >>>>>>>>>>>> >>>>>>>>>>>> This patch has one behavioral difference; when printing flags with e.g. PrintFlagsFinal in a debug build it prints "develop" for develop flags: >>>>>>>>>>>> >>>>>>>>>>>> uintx AdaptiveSizePolicyGCTimeLimitThreshold = 5 {develop} >>>>>>>>>>>> >>>>>>>>>>>> The output for product builds is unchanged. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From thomas.schatzl at oracle.com Thu Sep 26 12:04:23 2013 From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com) Date: Thu, 26 Sep 2013 19:04:23 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20130926190444.65F1F62B1C@hg.openjdk.java.net> Changeset: 2c022e432e10 Author: stefank Date: 2013-09-20 10:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c022e432e10 8024974: Incorrect use of GC_locker::is_active() Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint. Reviewed-by: brutisso, dcubed Contributed-by: per.liden at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 9361de86a50f Author: stefank Date: 2013-09-20 11:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9361de86a50f 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Reviewed-by: coleenp, brutisso, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: b960c9df4f11 Author: stefank Date: 2013-09-21 10:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b960c9df4f11 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Reviewed-by: coleenp, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 10cc3b624f8f Author: tschatzl Date: 2013-09-24 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/10cc3b624f8f Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: a19bea467577 Author: tschatzl Date: 2013-09-25 13:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a19bea467577 7163191: G1: introduce a "heap spanning table" abstraction Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class. Reviewed-by: brutisso ! make/excludeSrc.make + src/share/vm/gc_implementation/g1/g1BiasedArray.cpp + src/share/vm/gc_implementation/g1/g1BiasedArray.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/jni.cpp Changeset: 03f493ce3a71 Author: brutisso Date: 2013-09-25 17:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/03f493ce3a71 8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 461159cd7a91 Author: tschatzl Date: 2013-09-26 12:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/461159cd7a91 Merge ! src/share/vm/classfile/symbolTable.cpp Changeset: 3da9fad1391e Author: tschatzl Date: 2013-09-26 06:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3da9fad1391e Merge From john.coomes at oracle.com Thu Sep 26 12:24:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:24:39 +0000 Subject: hg: hsx/hotspot-main/corba: 2 new changesets Message-ID: <20130926192445.3072462B1E@hg.openjdk.java.net> Changeset: 428428cf5e06 Author: tbell Date: 2013-09-25 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/428428cf5e06 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: 3d2b7ce93c5c Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/3d2b7ce93c5c Added tag jdk8-b109 for changeset 428428cf5e06 ! .hgtags From john.coomes at oracle.com Thu Sep 26 12:25:36 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:25:36 +0000 Subject: hg: hsx/hotspot-main/jaxws: 2 new changesets Message-ID: <20130926192547.3865662B20@hg.openjdk.java.net> Changeset: df5d4d016425 Author: tbell Date: 2013-09-25 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/df5d4d016425 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: cc682329886b Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/cc682329886b Added tag jdk8-b109 for changeset df5d4d016425 ! .hgtags From john.coomes at oracle.com Thu Sep 26 12:25:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:25:00 +0000 Subject: hg: hsx/hotspot-main/jaxp: 2 new changesets Message-ID: <20130926192516.97D5A62B1F@hg.openjdk.java.net> Changeset: 02bfab2aa938 Author: tbell Date: 2013-09-25 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/02bfab2aa938 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: 4c84c5b447b0 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4c84c5b447b0 Added tag jdk8-b109 for changeset 02bfab2aa938 ! .hgtags From john.coomes at oracle.com Thu Sep 26 12:24:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:24:24 +0000 Subject: hg: hsx/hotspot-main: 2 new changesets Message-ID: <20130926192425.2835B62B1D@hg.openjdk.java.net> Changeset: 91f47e8da5c6 Author: tbell Date: 2013-09-25 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/91f47e8da5c6 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: 0cc21882d2f6 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0cc21882d2f6 Added tag jdk8-b109 for changeset 91f47e8da5c6 ! .hgtags From john.coomes at oracle.com Thu Sep 26 12:29:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:29:14 +0000 Subject: hg: hsx/hotspot-main/langtools: 2 new changesets Message-ID: <20130926192948.EDC7762B23@hg.openjdk.java.net> Changeset: 985abf1cd327 Author: tbell Date: 2013-09-25 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/985abf1cd327 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: 6f11dc295641 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6f11dc295641 Added tag jdk8-b109 for changeset 985abf1cd327 ! .hgtags From john.coomes at oracle.com Thu Sep 26 12:30:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:30:09 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b109 for changeset 6ec2f9e5ed5b Message-ID: <20130926193016.606D762B26@hg.openjdk.java.net> Changeset: d1e2050e575e Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d1e2050e575e Added tag jdk8-b109 for changeset 6ec2f9e5ed5b ! .hgtags From john.coomes at oracle.com Thu Sep 26 12:26:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 26 Sep 2013 19:26:09 +0000 Subject: hg: hsx/hotspot-main/jdk: 2 new changesets Message-ID: <20130926192755.465A462B21@hg.openjdk.java.net> Changeset: 946f3fd5f8bf Author: tbell Date: 2013-09-25 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/946f3fd5f8bf 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties ! makefiles/jprt.properties Changeset: f8c9a4b80148 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8c9a4b80148 Added tag jdk8-b109 for changeset 946f3fd5f8bf ! .hgtags From christian.thalinger at oracle.com Thu Sep 26 19:19:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 26 Sep 2013 19:19:10 -0700 Subject: JDK7u, hotspot, CC_INTERP, and COBOL In-Reply-To: <524322D3.4050000@orange.fr> References: <524322D3.4050000@orange.fr> Message-ID: On Sep 25, 2013, at 10:52 AM, Francis ANDRE wrote: > Hi > > On WXP with VS2010 and the http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/ repository, I successfully build and ran the debug version of hotspot in compiler1 directory. fine > > Next, I tried to get working the bytecode cppInterpreter instead of the template based interpreter adding the CC_INTERP=true preprocessor define, but I got several compile errors -- see below -- > > By looking at the Wiki and the OpenJDK website, I discovered that the cppInterpreter was no more maintained. I have no idea if it works on Windows but on Linux you can build Zero: http://openjdk.java.net/projects/zero/ Zero uses the C++ interpreter. > > So I am wondering why the cppInterpreter is not anymore maintained and would like to understand if this decision is definitive or not, because it seems to me that there are very few errors. (see above) and that, IMHO, a somewhat small effort should be made to fix the cppInterpreter (but it could be totally wrong). > > I need the cppInterpreter to make a proposal to the MLVM project to slightly change the JVM spec for all xALOAD and xASTORE bytecodes for a specific class version number for an efficient support of a _COBOL __runtime_. > > Regards > > Francis > > > cppInterpreter_x86.cpp > 1> frame_x86.cpp > 1> interpreter_x86_32.cpp > 1> interp_masm_x86_32.cpp > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039: 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065: 'interpreter_frame_sender_sp_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039: 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065: 'interpreter_frame_last_sp_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039: 'interpreter_frame_method_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065: 'interpreter_frame_method_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039: 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065: 'interpreter_frame_mdx_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039: 'interpreter_frame_cache_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065: 'interpreter_frame_cache_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039: 'interpreter_frame_locals_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065: 'interpreter_frame_locals_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039: 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065: 'interpreter_frame_bcx_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039: 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065: 'interpreter_frame_initial_sp_offset' : identificateur non d?clar? > 1> sharedRuntime_x86_32.cpp > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220: avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146: op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039: 'increment_mask_and_jump' : n'est pas membre de 'InterpreterMacroAssembler' > 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur de syntaxe : identificateur 'Condition' > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl' : identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861: 'incrementl' : identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl' : identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl' : identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' : identificateur introuvable > 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039: 'empty_expression_stack' : n'est pas membre de 'InterpreterMacroAssembler' > 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' > 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039: 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler' > 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: 'method_handle' : n'est pas membre de 'Interpreter' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143) : voir la d?claration de 'Interpreter' > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065: 'method_handle' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051: l'expression associ?e ? case n'est pas une constante > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: 'generate_method_handle_entry' : n'est pas membre de 'InterpreterGenerator' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37) : voir la d?claration de 'InterpreterGenerator' > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le terme ne correspond pas ? une fonction qui prend 0 arguments > 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220: avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? > 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146: op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? > ========== G?n?ration : 0 a r?ussi, 1 a ?chou?, 0 mis ? jour, 0 a ?t? ignor? ========== > > > > > From francis.andre.kampbell at orange.fr Thu Sep 26 19:40:33 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Fri, 27 Sep 2013 04:40:33 +0200 Subject: JDK7u, hotspot, CC_INTERP, and COBOL In-Reply-To: References: <524322D3.4050000@orange.fr> Message-ID: <5244F021.8060803@orange.fr> Hi Christian Ok, I will have a look at Zero and try to make it on windows. Thanks for the pointer. Le 27/09/2013 04:19, Christian Thalinger a ?crit : > On Sep 25, 2013, at 10:52 AM, Francis ANDRE wrote: > >> Hi >> >> On WXP with VS2010 and the http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/ repository, I successfully build and ran the debug version of hotspot in compiler1 directory. fine >> >> Next, I tried to get working the bytecode cppInterpreter instead of the template based interpreter adding the CC_INTERP=true preprocessor define, but I got several compile errors -- see below -- >> >> By looking at the Wiki and the OpenJDK website, I discovered that the cppInterpreter was no more maintained. > I have no idea if it works on Windows but on Linux you can build Zero: > > http://openjdk.java.net/projects/zero/ > > Zero uses the C++ interpreter. > >> So I am wondering why the cppInterpreter is not anymore maintained and would like to understand if this decision is definitive or not, because it seems to me that there are very few errors. (see above) and that, IMHO, a somewhat small effort should be made to fix the cppInterpreter (but it could be totally wrong). >> >> I need the cppInterpreter to make a proposal to the MLVM project to slightly change the JVM spec for all xALOAD and xASTORE bytecodes for a specific class version number for an efficient support of a _COBOL __runtime_. >> >> Regards >> >> Francis >> >> >> cppInterpreter_x86.cpp >> 1> frame_x86.cpp >> 1> interpreter_x86_32.cpp >> 1> interp_masm_x86_32.cpp >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039: 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065: 'interpreter_frame_sender_sp_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039: 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065: 'interpreter_frame_last_sp_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039: 'interpreter_frame_method_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065: 'interpreter_frame_method_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039: 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065: 'interpreter_frame_mdx_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039: 'interpreter_frame_cache_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065: 'interpreter_frame_cache_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039: 'interpreter_frame_locals_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065: 'interpreter_frame_locals_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039: 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065: 'interpreter_frame_bcx_offset' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039: 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la d?claration de 'frame' >> 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065: 'interpreter_frame_initial_sp_offset' : identificateur non d?clar? >> 1> sharedRuntime_x86_32.cpp >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220: avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146: op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039: 'increment_mask_and_jump' : n'est pas membre de 'InterpreterMacroAssembler' >> 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur de syntaxe : identificateur 'Condition' >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl' : identificateur introuvable >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861: 'incrementl' : identificateur introuvable >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl' : identificateur introuvable >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl' : identificateur introuvable >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' : identificateur introuvable >> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039: 'empty_expression_stack' : n'est pas membre de 'InterpreterMacroAssembler' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' >> 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039: 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir la d?claration de 'InterpreterMacroAssembler' >> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: 'method_handle' : n'est pas membre de 'Interpreter' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143) : voir la d?claration de 'Interpreter' >> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065: 'method_handle' : identificateur non d?clar? >> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051: l'expression associ?e ? case n'est pas une constante >> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: 'generate_method_handle_entry' : n'est pas membre de 'InterpreterGenerator' >> 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37) : voir la d?claration de 'InterpreterGenerator' >> 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le terme ne correspond pas ? une fonction qui prend 0 arguments >> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220: avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? >> 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146: op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? >> ========== G?n?ration : 0 a r?ussi, 1 a ?chou?, 0 mis ? jour, 0 a ?t? ignor? ========== >> >> >> >> >> > From alejandro.murillo at oracle.com Thu Sep 26 20:12:58 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 27 Sep 2013 03:12:58 +0000 Subject: hg: hsx/hsx25/hotspot: 39 new changesets Message-ID: <20130927031436.0A52D62B53@hg.openjdk.java.net> Changeset: c81dd5393a5e Author: tbell Date: 2013-09-25 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c81dd5393a5e 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: fff4842215d1 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fff4842215d1 Added tag jdk8-b109 for changeset c81dd5393a5e ! .hgtags Changeset: 8a6a85321d3a Author: amurillo Date: 2013-09-20 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8a6a85321d3a 8025127: new hotspot build - hs25-b52 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63147986a428 Author: dcubed Date: 2013-09-18 07:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/63147986a428 8019835: Strings interned in different threads equal but does not == Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants. Reviewed-by: rdurbin, sspitsyn, coleenp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: dfae98867ee8 Author: dholmes Date: 2013-09-18 20:08 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dfae98867ee8 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps Reviewed-by: alanb, chegar, dholmes, ksrini Contributed-by: Mike Duigou ! src/share/vm/runtime/arguments.cpp Changeset: c1d7040a1183 Author: sgabdura Date: 2013-09-18 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c1d7040a1183 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor() Reviewed-by: dcubed, dsamersoff ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 8c84f04ff977 Author: kevinw Date: 2013-09-18 19:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8c84f04ff977 Merge Changeset: 6eb908998b32 Author: kevinw Date: 2013-09-19 08:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6eb908998b32 Merge Changeset: 9ed97b511b26 Author: hseigel Date: 2013-09-19 11:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9ed97b511b26 8024517: runtime/CDSCompressedKPtrs/XShareAuto.java failed with RuntimeException Summary: Make sure CDS is off by default when running server compiler. Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/arguments.cpp ! test/runtime/CDSCompressedKPtrs/XShareAuto.java Changeset: 4f9a42c33738 Author: coleenp Date: 2013-09-20 09:30 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4f9a42c33738 8022887: Assertion hit while using class and redefining it with RedefineClasses simultaneously Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: dcubed, sspitsyn ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp Changeset: f201713502e0 Author: coleenp Date: 2013-09-20 09:44 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f201713502e0 Merge Changeset: 1b03bed31241 Author: allwin Date: 2013-09-17 17:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b03bed31241 7196151: ParserTest SEGv on solaris Reviewed-by: sla, coleenp, ctornqvi, dsamersoff ! src/share/vm/services/diagnosticArgument.cpp Changeset: e5a25e4ae509 Author: mgerdin Date: 2013-09-20 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e5a25e4ae509 Merge Changeset: 7c29904fdfa2 Author: coleenp Date: 2013-09-20 18:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7c29904fdfa2 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solaris 64 Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found. Reviewed-by: hseigel, dcubed, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: df03413ad1a9 Author: coleenp Date: 2013-09-21 01:45 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df03413ad1a9 Merge Changeset: 0f37d1badced Author: dcubed Date: 2013-09-20 12:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f37d1badced Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a7609ec351d6 Author: dcubed Date: 2013-09-20 18:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a7609ec351d6 Merge ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 8ddc26f62476 Author: sla Date: 2013-09-22 06:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8ddc26f62476 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" Reviewed-by: sla, dsamersoff Contributed-by: Yasumasa Suenaga ! src/share/vm/services/attachListener.cpp Changeset: 1f42d3ec1759 Author: dsamersoff Date: 2013-09-22 18:49 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f42d3ec1759 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not Summary: replace PT_LOAD segment with library segment when necessary Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ae2edb3df7fb Author: dsamersoff Date: 2013-09-22 18:07 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ae2edb3df7fb Merge Changeset: 084b21cd0228 Author: iklam Date: 2013-09-23 08:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/084b21cd0228 8025088: Missing cases for JVM_CONSTANT_MethodHandleInError cause crash if debugger steps into error-tagged method handle Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: e8a0010ba69e Author: zgu Date: 2013-09-25 13:03 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e8a0010ba69e Merge Changeset: 891687731b59 Author: anoll Date: 2013-09-24 15:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/891687731b59 7009641: Don't fail VM when CodeCache is full Summary: Allocation in the code cache returns NULL instead of failing the entire VM Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 1b64d46620a3 Author: kvn Date: 2013-09-24 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b64d46620a3 8022585: VM crashes when ran with -XX:+PrintInlining Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method. Reviewed-by: twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/print/PrintInlining.java Changeset: f637d4dc21bb Author: adlertz Date: 2013-09-26 08:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f637d4dc21bb Merge Changeset: 586fa1919a89 Author: bpittore Date: 2013-09-20 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/586fa1919a89 8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true' Reviewed-by: kvn, twisti, dholmes ! src/share/vm/runtime/vm_version.hpp Changeset: 504d8f519adf Author: jiangli Date: 2013-09-20 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/504d8f519adf Merge Changeset: d682c6e24fe3 Author: bdelsart Date: 2013-09-26 01:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d682c6e24fe3 Merge Changeset: 60a2d625db36 Author: bdelsart Date: 2013-09-26 04:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/60a2d625db36 Merge Changeset: 2c022e432e10 Author: stefank Date: 2013-09-20 10:53 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c022e432e10 8024974: Incorrect use of GC_locker::is_active() Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint. Reviewed-by: brutisso, dcubed Contributed-by: per.liden at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 9361de86a50f Author: stefank Date: 2013-09-20 11:00 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9361de86a50f 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Reviewed-by: coleenp, brutisso, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: b960c9df4f11 Author: stefank Date: 2013-09-21 10:09 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b960c9df4f11 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Reviewed-by: coleenp, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 10cc3b624f8f Author: tschatzl Date: 2013-09-24 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/10cc3b624f8f Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: a19bea467577 Author: tschatzl Date: 2013-09-25 13:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a19bea467577 7163191: G1: introduce a "heap spanning table" abstraction Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class. Reviewed-by: brutisso ! make/excludeSrc.make + src/share/vm/gc_implementation/g1/g1BiasedArray.cpp + src/share/vm/gc_implementation/g1/g1BiasedArray.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/jni.cpp Changeset: 03f493ce3a71 Author: brutisso Date: 2013-09-25 17:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/03f493ce3a71 8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 461159cd7a91 Author: tschatzl Date: 2013-09-26 12:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/461159cd7a91 Merge ! src/share/vm/classfile/symbolTable.cpp Changeset: 3da9fad1391e Author: tschatzl Date: 2013-09-26 06:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3da9fad1391e Merge Changeset: 58043478c26d Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/58043478c26d Merge Changeset: 6209b0ed51c0 Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6209b0ed51c0 Added tag hs25-b52 for changeset 58043478c26d ! .hgtags From alejandro.murillo at oracle.com Thu Sep 26 23:22:05 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 27 Sep 2013 06:22:05 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130927062225.8251762B59@hg.openjdk.java.net> Changeset: c81dd5393a5e Author: tbell Date: 2013-09-25 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c81dd5393a5e 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: fff4842215d1 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fff4842215d1 Added tag jdk8-b109 for changeset c81dd5393a5e ! .hgtags Changeset: 58043478c26d Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/58043478c26d Merge Changeset: 6209b0ed51c0 Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6209b0ed51c0 Added tag hs25-b52 for changeset 58043478c26d ! .hgtags Changeset: 24250c363d7f Author: amurillo Date: 2013-09-26 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24250c363d7f 8025536: new hotspot build - hs25-b53 Reviewed-by: jcoomes ! make/hotspot_version From kevin.walls at oracle.com Fri Sep 27 08:07:47 2013 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Fri, 27 Sep 2013 15:07:47 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20130927150757.0645862B85@hg.openjdk.java.net> Changeset: 48f2de0394ac Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/48f2de0394ac 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp Changeset: 5b384761ab6e Author: kevinw Date: 2013-09-09 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/5b384761ab6e 8023478: Test fails with HS crash in GCNotifier. Reviewed-by: sla ! src/share/vm/services/gcNotifier.cpp From christian.thalinger at oracle.com Fri Sep 27 17:41:04 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 27 Sep 2013 17:41:04 -0700 Subject: RFR (S): 8025613: clang: remove -Wno-unused-value Message-ID: https://bugs.openjdk.java.net/browse/JDK-8025613 http://cr.openjdk.java.net/~twisti/8025613/webrev.00/ 8025613: clang: remove -Wno-unused-value Reviewed-by: Some small fixes so we can enable -Wunused-value. From igor.veresov at oracle.com Fri Sep 27 23:57:47 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 28 Sep 2013 10:57:47 +0400 Subject: RFR (S): 8025613: clang: remove -Wno-unused-value In-Reply-To: References: Message-ID: <9CAD0B71-78CA-4940-A94F-5741555DAD10@oracle.com> Looks good. igor On Sep 28, 2013, at 4:41 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8025613 > http://cr.openjdk.java.net/~twisti/8025613/webrev.00/ > > 8025613: clang: remove -Wno-unused-value > Reviewed-by: > > Some small fixes so we can enable -Wunused-value. > From christian.thalinger at oracle.com Sat Sep 28 12:35:05 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sat, 28 Sep 2013 12:35:05 -0700 Subject: RFR (S): 8025613: clang: remove -Wno-unused-value In-Reply-To: <9CAD0B71-78CA-4940-A94F-5741555DAD10@oracle.com> References: <9CAD0B71-78CA-4940-A94F-5741555DAD10@oracle.com> Message-ID: <9ECD33FD-AA0C-4AA4-88A4-BAA1FAB5DEEE@oracle.com> Thank you, Igor. On Sep 27, 2013, at 11:57 PM, Igor Veresov wrote: > Looks good. > > igor > > On Sep 28, 2013, at 4:41 AM, Christian Thalinger wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8025613 >> http://cr.openjdk.java.net/~twisti/8025613/webrev.00/ >> >> 8025613: clang: remove -Wno-unused-value >> Reviewed-by: >> >> Some small fixes so we can enable -Wunused-value. >> > From ioi.lam at oracle.com Sat Sep 28 12:50:48 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 28 Sep 2013 12:50:48 -0700 Subject: Visual Studio project creator In-Reply-To: References: Message-ID: <52473318.7020201@oracle.com> #3 is https://bugs.openjdk.java.net/browse/JDK-6975479. It has not been fixed yet. It seems harmless .... - Ioi On 09/25/2013 05:12 AM, Ivan Krylov wrote: > Folks, > > I am not sure who is maintaining the visual studio project generator these days. It used to be the Runtime team in the past including myself. > > I just created a jvm project for Visual Studio out of hsx 24 (7u40) using hotspot\make\windows\create and I am seeing errors. > > Out of the batch build all job I get this: > ========== Rebuild All: 3 succeeded, 9 failed, 0 skipped ========== > > I see several errors > > 1) the definitions in globals.hpp are guarded with > #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) > which is not true for core targets > > ClCompile: > java.cpp > c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/globals.hpp(170): error C2370: 'pd_InlineSmallCode' : redefinition; different storage class > c:\dev\jdk7u40-vanilla\hotspot\src\cpu\x86\vm\globals_x86.hpp(56) : see declaration of 'pd_InlineSmallCode' > > 2) Missing an include directory for the generated jvmtifiles > ClCompile: > java.cpp > c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/os.hpp(28): fatal error C1083: Cannot open include file: 'jvmtifiles/jvmti.h': No such file or directory > > 3) I also get the following warning: > > > jni.obj : warning LNK4197: export 'JNI_GetDefaultJavaVMInitArgs' specified multiple times; using first specification > jni.obj : warning LNK4197: export 'JNI_GetCreatedJavaVMs' specified multiple times; using first specification > jni.obj : warning LNK4197: export 'JNI_CreateJavaVM' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_vsnprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_snprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_vfprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_printf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_GetVersionInfo' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_fprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_InitAgentProperties' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateValues' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_FindClassFromBootLoader' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified multiple times; using first specification > Creating library c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.lib and object c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.exp > jvm.vcxproj -> c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.dll > PostBuildEvent: > Description: Building hotspot.exe... > > > 1 and 2 should be easy to fix, 3 - I am not sure. > Since I am looking at u40 could this have been fixed since then? > > Thanks, > > Ivan From francis.andre.kampbell at orange.fr Sun Sep 29 01:10:50 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sun, 29 Sep 2013 10:10:50 +0200 Subject: Visual Studio project creator In-Reply-To: References: Message-ID: <5247E08A.8090900@orange.fr> Hi Yvan I just checked out hg clone http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/hotspot/ and run without any errors create C:\Progra~1\Java\jdk1.7.0_40 The solution generated by create.bat is also compiling fine 1> java.c 1> mkdir launcher 2>NUL >NUL 1> cl /nologo /W3 /WX /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /D FULL_VERSION=\""\\\"24.0-b56-internal\\\""\" /D JDK_MAJOR_VERSION=\"\" /D JDK_MINOR_VERSION=\"\" /D GAMMA /D LAUNCHER_TYPE=\"gamma\" /D _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE /D LINK_INTO_LIBJVM /I Z:\DEV\OpenJDK_7u40\hotspot\\src\os\windows\launcher /I Z:\DEV\OpenJDK_7u40\hotspot\\src\share\tools\launcher /I Z:\DEV\OpenJDK_7u40\hotspot\\src\share\vm\prims /I Z:\DEV\OpenJDK_7u40\hotspot\\src\share\vm /I Z:\DEV\OpenJDK_7u40\hotspot\\src\cpu\x86\vm /I Z:\DEV\OpenJDK_7u40\hotspot\\src\os\windows\vm /c /Folauncher\java_md.obj Z:\DEV\OpenJDK_7u40\hotspot\/src/os/windows/launcher\java_md.c 1> java_md.c 1> mkdir launcher 2>NUL >NUL 1> cl /nologo /W3 /WX /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /D FULL_VERSION=\""\\\"24.0-b56-internal\\\""\" /D JDK_MAJOR_VERSION=\"\" /D JDK_MINOR_VERSION=\"\" /D GAMMA /D LAUNCHER_TYPE=\"gamma\" /D _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE /D LINK_INTO_LIBJVM /I Z:\DEV\OpenJDK_7u40\hotspot\\src\os\windows\launcher /I Z:\DEV\OpenJDK_7u40\hotspot\\src\share\tools\launcher /I Z:\DEV\OpenJDK_7u40\hotspot\\src\share\vm\prims /I Z:\DEV\OpenJDK_7u40\hotspot\\src\share\vm /I Z:\DEV\OpenJDK_7u40\hotspot\\src\cpu\x86\vm /I Z:\DEV\OpenJDK_7u40\hotspot\\src\os\windows\vm /c /Folauncher\jli_util.obj Z:\DEV\OpenJDK_7u40\hotspot\/src/share/tools/launcher\jli_util.c 1> jli_util.c 1> echo C:\Progra~1\Java\jdk1.7.0_40 > jdkpath.txt 1> link.exe /SAFESEH /manifest jvm.lib kernel32.lib user32.lib /nologo /machine:I386 /map /debug /subsystem:console /out:hotspot.exe launcher\java.obj launcher\java_md.obj launcher\jli_util.obj ========== G?n?ration : 1 a r?ussi, 0 a ?chou?, 0 mis ? jour, 0 a ?t? ignor? ========== Francis Le 25/09/2013 14:12, Ivan Krylov a ?crit : > Folks, > > I am not sure who is maintaining the visual studio project generator these days. It used to be the Runtime team in the past including myself. > > I just created a jvm project for Visual Studio out of hsx 24 (7u40) using hotspot\make\windows\create and I am seeing errors. > > Out of the batch build all job I get this: > ========== Rebuild All: 3 succeeded, 9 failed, 0 skipped ========== > > I see several errors > > 1) the definitions in globals.hpp are guarded with > #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) > which is not true for core targets > > ClCompile: > java.cpp > c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/globals.hpp(170): error C2370: 'pd_InlineSmallCode' : redefinition; different storage class > c:\dev\jdk7u40-vanilla\hotspot\src\cpu\x86\vm\globals_x86.hpp(56) : see declaration of 'pd_InlineSmallCode' > > 2) Missing an include directory for the generated jvmtifiles > ClCompile: > java.cpp > c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/os.hpp(28): fatal error C1083: Cannot open include file: 'jvmtifiles/jvmti.h': No such file or directory > > 3) I also get the following warning: > > > jni.obj : warning LNK4197: export 'JNI_GetDefaultJavaVMInitArgs' specified multiple times; using first specification > jni.obj : warning LNK4197: export 'JNI_GetCreatedJavaVMs' specified multiple times; using first specification > jni.obj : warning LNK4197: export 'JNI_CreateJavaVM' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_vsnprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_snprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_vfprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_printf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_GetVersionInfo' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'jio_fprintf' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_InitAgentProperties' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateValues' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_FindClassFromBootLoader' specified multiple times; using first specification > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified multiple times; using first specification > Creating library c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.lib and object c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.exp > jvm.vcxproj -> c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.dll > PostBuildEvent: > Description: Building hotspot.exe... > > > 1 and 2 should be easy to fix, 3 - I am not sure. > Since I am looking at u40 could this have been fixed since then? > > Thanks, > > Ivan From ivan at azulsystems.com Mon Sep 30 03:31:21 2013 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 30 Sep 2013 10:31:21 +0000 Subject: Visual Studio project creator In-Reply-To: <52473318.7020201@oracle.com> References: <52473318.7020201@oracle.com> Message-ID: <83A81ECB-A7BF-4DED-A094-8EC529BDE305@azulsystems.com> Yes, my error #2 was due to failures in create.bat. Can you confirm that you can build _all_ targets in VS2010? Thanks, Ivan On Sep 28, 2013, at 11:50 PM, Ioi Lam wrote: > #3 is https://bugs.openjdk.java.net/browse/JDK-6975479. It has not been fixed yet. > > It seems harmless .... > > - Ioi > > On 09/25/2013 05:12 AM, Ivan Krylov wrote: >> Folks, >> >> I am not sure who is maintaining the visual studio project generator these days. It used to be the Runtime team in the past including myself. >> >> I just created a jvm project for Visual Studio out of hsx 24 (7u40) using hotspot\make\windows\create and I am seeing errors. >> >> Out of the batch build all job I get this: >> ========== Rebuild All: 3 succeeded, 9 failed, 0 skipped ========== >> >> I see several errors >> >> 1) the definitions in globals.hpp are guarded with >> #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) >> which is not true for core targets >> >> ClCompile: >> java.cpp >> c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/globals.hpp(170): error C2370: 'pd_InlineSmallCode' : redefinition; different storage class >> c:\dev\jdk7u40-vanilla\hotspot\src\cpu\x86\vm\globals_x86.hpp(56) : see declaration of 'pd_InlineSmallCode' >> >> 2) Missing an include directory for the generated jvmtifiles >> ClCompile: >> java.cpp >> c:\dev\jdk7u40-vanilla\hotspot\src\share\vm\runtime/os.hpp(28): fatal error C1083: Cannot open include file: 'jvmtifiles/jvmti.h': No such file or directory >> >> 3) I also get the following warning: >> >> jni.obj : warning LNK4197: export 'JNI_GetDefaultJavaVMInitArgs' specified multiple times; using first specification >> jni.obj : warning LNK4197: export 'JNI_GetCreatedJavaVMs' specified multiple times; using first specification >> jni.obj : warning LNK4197: export 'JNI_CreateJavaVM' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'jio_vsnprintf' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'jio_snprintf' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'jio_vfprintf' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'jio_printf' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'JVM_GetVersionInfo' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'jio_fprintf' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'JVM_InitAgentProperties' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'JVM_GetThreadStateValues' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'JVM_FindClassFromBootLoader' specified multiple times; using first specification >> jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified multiple times; using first specification >> Creating library c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.lib and object c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.exp >> jvm.vcxproj -> c:\dev\jdk7u40-vanilla\hotspot\build\vs-amd64\compiler1\product\jvm.dll >> PostBuildEvent: >> Description: Building hotspot.exe... >> >> >> 1 and 2 should be easy to fix, 3 - I am not sure. >> Since I am looking at u40 could this have been fixed since then? >> >> Thanks, >> >> Ivan > From goetz.lindenmaier at sap.com Mon Sep 30 07:21:01 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Sep 2013 14:21:01 +0000 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D0324B5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D0324B5@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0D03547B@DEWDFEMB12A.global.corp.sap> Hi, could I please get some reviews on this change? Although this is marked 'L', this should not be too much as most of the code is guarded by ifdef CC_INTERP. Thanks and best regards, Goetz. From: goetz.lindenmaier at sap.com Sent: Sonntag, 15. September 2013 15:58 To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling Hi, http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ this change implements bytecode profiling for the cppInterpreter. It changes a row of shared files, but most of the changes are guarded by CC_INTERP. This is not mandatory, but I think it makes clear what the extensions are meant for, and assures it's not compiled into template interpreter builds. We desinged the bytecode profiling for the cppInterpreter to deliver exact the same counter values as the template interpreter does. E.g., we extended the interpreter to also check backedge counts. The macros used in the interpreter loop are placed in a new file bytecodeInterpreterProfiling.hpp. I'm happy to move them somewhere else. The code is guarded with CC_INTERP_PROFILE, which is only enabled if COMPILER2 is set. Thus, ZERO will not encounter any overhead in the interpreter loop. This change also enables all the new features we implemented in the cppInterpreter, see arguments.cpp. Although this change is marked as L, it should not have an effect on non-cppInterpreter platforms. Please review and test this change. Best regards, Goetz. From volker.simonis at gmail.com Mon Sep 30 08:37:45 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 30 Sep 2013 17:37:45 +0200 Subject: JDK7u, hotspot, CC_INTERP, and COBOL In-Reply-To: <524322D3.4050000@orange.fr> References: <524322D3.4050000@orange.fr> Message-ID: Just for reference: we have a running CPP-Interpreter on Linux/PPC64 with some enhancements like profiling, compressed oops, OSR, JSR292 and Biased Locking. So in the case you want to fix it on x86, you may take the PPC64 implementation as a boiler plate: http://hg.openjdk.java.net/ppc-aix-port/jdk7u http://hg.openjdk.java.net/ppc-aix-port/jdk8 Regards, Volker On Wed, Sep 25, 2013 at 7:52 PM, Francis ANDRE wrote: > Hi > > On WXP with VS2010 and the http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/ > repository, I successfully build and ran the debug version of hotspot in > compiler1 directory. fine > > Next, I tried to get working the bytecode cppInterpreter instead of the > template based interpreter adding the CC_INTERP=true preprocessor define, > but I got several compile errors -- see below -- > > By looking at the Wiki and the OpenJDK website, I discovered that the > cppInterpreter was no more maintained. > > So I am wondering why the cppInterpreter is not anymore maintained and would > like to understand if this decision is definitive or not, because it seems > to me that there are very few errors. (see above) and that, IMHO, a somewhat > small effort should be made to fix the cppInterpreter (but it could be > totally wrong). > > I need the cppInterpreter to make a proposal to the MLVM project to slightly > change the JVM spec for all xALOAD and xASTORE bytecodes for a specific > class version number for an efficient support of a _COBOL __runtime_. > > Regards > > Francis > > > cppInterpreter_x86.cpp > 1> frame_x86.cpp > 1> interpreter_x86_32.cpp > 1> interp_masm_x86_32.cpp > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039: > 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065: > 'interpreter_frame_sender_sp_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039: > 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065: > 'interpreter_frame_last_sp_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039: > 'interpreter_frame_method_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065: > 'interpreter_frame_method_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039: > 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065: > 'interpreter_frame_mdx_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039: > 'interpreter_frame_cache_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065: > 'interpreter_frame_cache_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039: > 'interpreter_frame_locals_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065: > 'interpreter_frame_locals_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039: > 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065: > 'interpreter_frame_bcx_offset' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039: > 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la > d?claration de 'frame' > 1>..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065: > 'interpreter_frame_initial_sp_offset' : identificateur non d?clar? > 1> sharedRuntime_x86_32.cpp > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220: > avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146: op?rateur > moins unaire appliqu? ? un type non sign?, le r?sultat sera non sign? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039: > 'increment_mask_and_jump' : n'est pas membre de 'InterpreterMacroAssembler' > 1> z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir > la d?claration de 'InterpreterMacroAssembler' > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur de > syntaxe : identificateur 'Condition' > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl' : > identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): error C3861: > 'incrementl' : identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1422): error C3861: 'movl' : > identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1423): error C3861: 'andl' : > identificateur introuvable > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'cond' : > identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C2065: 'where' : > identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1424): error C3861: 'jcc' : > identificateur introuvable > 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(233): error C2039: > 'empty_expression_stack' : n'est pas membre de 'InterpreterMacroAssembler' > 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir > la d?claration de 'InterpreterMacroAssembler' > 1>..\..\src\cpu\x86\vm\interpreter_x86_32.cpp(235): error C2039: > 'restore_locals' : n'est pas membre de 'InterpreterMacroAssembler' > 1> Z:\DEV\OpenJDK7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir > la d?claration de 'InterpreterMacroAssembler' > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: > 'method_handle' : n'est pas membre de 'Interpreter' > 1> Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreter.hpp(143) : > voir la d?claration de 'Interpreter' > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2065: > 'method_handle' : identificateur non d?clar? > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2051: > l'expression associ?e ? case n'est pas une constante > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2211): error C2039: > 'generate_method_handle_entry' : n'est pas membre de 'InterpreterGenerator' > 1> > Z:\DEV\OpenJDK7u\hotspot\src\share\vm\interpreter/interpreterGenerator.hpp(37) > : voir la d?claration de 'InterpreterGenerator' > 1>..\..\src\cpu\x86\vm\cppInterpreter_x86.cpp(2255): error C2064: le terme > ne correspond pas ? une fonction qui prend 0 arguments > 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): error C2220: > avertissement consid?r? comme une erreur - aucun fichier 'object' g?n?r? > 1>..\..\src\cpu\x86\vm\sharedRuntime_x86_32.cpp(3062): warning C4146: > op?rateur moins unaire appliqu? ? un type non sign?, le r?sultat sera non > sign? > ========== G?n?ration : 0 a r?ussi, 1 a ?chou?, 0 mis ? jour, 0 a ?t? ignor? > ========== > > > > > From mikael.vidstedt at oracle.com Mon Sep 30 17:26:40 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 30 Sep 2013 17:26:40 -0700 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions Message-ID: <524A16C0.4080606@oracle.com> Folks, Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8024087 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.00/webrev/ Summary: This change removes two JVM_* functions - JVM_GetPrimitiveFieldValues and JVM_SetPrimitiveFieldValues. These functions were used back in JDK 1.3.1 to intrinsify two java.io.Object{Input,Output}Stream methods, but the Java code was rewritten in the JDK 1.4 time frame and the corresponding Java methods are no longer there, meaning this code is well and truly dead and has been so for many years. On top of that the functions only have prototypes declared in jvm_misc.hpp (as opposed to jvm.h etc), meaning the risk of somebody depending on these functions is further limited. My non-extensive (re-)search of the web appears to confirm this. Thanks, Mikael From coleen.phillimore at oracle.com Mon Sep 30 17:45:43 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 30 Sep 2013 20:45:43 -0400 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions In-Reply-To: <524A16C0.4080606@oracle.com> References: <524A16C0.4080606@oracle.com> Message-ID: <524A1B37.4060900@oracle.com> Looks good! Coleen On 09/30/2013 08:26 PM, Mikael Vidstedt wrote: > > Folks, > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8024087 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.00/webrev/ > > > Summary: > > This change removes two JVM_* functions - JVM_GetPrimitiveFieldValues > and JVM_SetPrimitiveFieldValues. These functions were used back in JDK > 1.3.1 to intrinsify two java.io.Object{Input,Output}Stream methods, > but the Java code was rewritten in the JDK 1.4 time frame and the > corresponding Java methods are no longer there, meaning this code is > well and truly dead and has been so for many years. > > On top of that the functions only have prototypes declared in > jvm_misc.hpp (as opposed to jvm.h etc), meaning the risk of somebody > depending on these functions is further limited. My non-extensive > (re-)search of the web appears to confirm this. > > Thanks, > Mikael > From christian.tornqvist at oracle.com Mon Sep 30 17:56:14 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 30 Sep 2013 20:56:14 -0400 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions In-Reply-To: <524A16C0.4080606@oracle.com> References: <524A16C0.4080606@oracle.com> Message-ID: <292201cebe41$07c648b0$1752da10$@oracle.com> Hi Mikael, Looks good, thanks for cleaning this up. Thanks, Christian -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Mikael Vidstedt Sent: Monday, September 30, 2013 8:27 PM To: hotspot-dev developers Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions Folks, Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8024087 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.00/webrev/ Summary: This change removes two JVM_* functions - JVM_GetPrimitiveFieldValues and JVM_SetPrimitiveFieldValues. These functions were used back in JDK 1.3.1 to intrinsify two java.io.Object{Input,Output}Stream methods, but the Java code was rewritten in the JDK 1.4 time frame and the corresponding Java methods are no longer there, meaning this code is well and truly dead and has been so for many years. On top of that the functions only have prototypes declared in jvm_misc.hpp (as opposed to jvm.h etc), meaning the risk of somebody depending on these functions is further limited. My non-extensive (re-)search of the web appears to confirm this. Thanks, Mikael From christian.thalinger at oracle.com Mon Sep 30 18:27:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 30 Sep 2013 18:27:26 -0700 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions In-Reply-To: <524A16C0.4080606@oracle.com> References: <524A16C0.4080606@oracle.com> Message-ID: SAP is still using this, I suppose, but they will maintain their own version. I applaud old code removal. Looks good. On Sep 30, 2013, at 5:26 PM, Mikael Vidstedt wrote: > > Folks, > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8024087 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.00/webrev/ > > > Summary: > > This change removes two JVM_* functions - JVM_GetPrimitiveFieldValues and JVM_SetPrimitiveFieldValues. These functions were used back in JDK 1.3.1 to intrinsify two java.io.Object{Input,Output}Stream methods, but the Java code was rewritten in the JDK 1.4 time frame and the corresponding Java methods are no longer there, meaning this code is well and truly dead and has been so for many years. > > On top of that the functions only have prototypes declared in jvm_misc.hpp (as opposed to jvm.h etc), meaning the risk of somebody depending on these functions is further limited. My non-extensive (re-)search of the web appears to confirm this. > > Thanks, > Mikael >