From dmitry.samersoff at oracle.com Tue Oct 1 05:29:27 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Oct 2013 16:29:27 +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: <524AC027.6010404@oracle.com> Mikael, Looks good for me. -Dmitry On 2013-10-01 04:26, 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 > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kozlov at oracle.com Tue Oct 1 11:25:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Oct 2013 11:25:19 -0700 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D03547B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D0324B5@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0D03547B@DEWDFEMB12A.global.corp.sap> Message-ID: <524B138F.4020208@oracle.com> TraceProfileInterpreter may be not good name. I first thought you implemented bytecodes trace profiling :) Can you change at least flag's comment to be clear that it is printing? Can you put under #ifdef CC_INTERP methods in invocationCounter.hpp which are used only by cppInterpreter? In general it is good I think. thanks, Vladimir On 9/30/13 7:21 AM, Lindenmaier, Goetz wrote: > 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 vladimir.kozlov at oracle.com Tue Oct 1 11:26:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Oct 2013 11:26:43 -0700 Subject: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. In-Reply-To: <524B0CE2.2040501@oracle.com> References: <524B0CE2.2040501@oracle.com> Message-ID: <524B13E3.8030007@oracle.com> Thank you, Goetz I think you described this enough for me to understand changes, You can push these changes now. We don't have closed code for adlc so I think it is safe to push it without JPRT. Thanks, Vladimir On 9/30/13 2:04 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> So you did all this to schedule IC load as separate instruction. Right? > More or less, yes. But not only the IC load. All nodes are broken down > so that they represent a single assembler instruction. (Except for real > big ones as string compare, sync ...). Mostly we use expand, but that's > not always possible. E.g. expanding DecodeN into add+shift early > can cause problems, if the intermediate value which is neither oop nor > narrow oop gets visible to GC. > >> Did you try to use 'expand %{ %}' for call node? We will generate >> separate mach nodes in such case. > I am using expand in several cases, but it does not work for call nodes. > Call nodes are very special. > > Best regards, > Goetz. > > On 9/24/13 6:44 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >>> First, when you say "constant pool" you really mean "constant section" >>> in nmethod. Right? And you want to load constants from it. >> Yes. >> >>> I would like to see you use our implementation of constant loads but it >>> is up to you if it does not affect our shared code. >> I use your functionality to get the constant into the pool, and to get the >> edge to the toc/constanttablebase. But then we split the constant load >> into two nodes, each encoding part of the offset into the pool. >> That's when I need these fields. >> Actually I fixed our nodes as far as possible to use that functionality >> when I first pushed the port into the jdk7 directory. >> >>> To have non-matching CallDynamicJavaDirect__2Node is interesting way to >>> not add new nodes to machnode.hpp. >>> >>> How you keep a live mach node which loads IC (do you have users/edges >>> pointing to it)? And how you scheduling it? And what about live range if >>> it is separated from call site? >> We add the toc/constanttablebase node to the call right after matching. >> Unfortunately constanttablebase can not be used in call nodes, so we >> Walk the graph and add it. We misuse in(TypeFunc::ReturnAdr) >> to point to toc. >> After register allocation we run the lateExpand phase. >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0115_8003850_opto-introduce_phase_lateExpand.patch >> This splits the call node into the individual instructions needed, >> which are two nodes for loading IC, two nodes for loading env ptr >> to r11, two nodes for loading the address, >> one node moving the address to the branch register, and >> the real call. This is then scheduled. The scheduler replaces >> Do_scheduling in output.cpp. >> >> I would like to improve handling constanttablebase with the Call node. There are >> Two problems: you can only use constanttablebase with constant nodes. >> But we need it with Call and storeCM, too. >> The other problem is that you can not add req edges to Call nodes. Therefore >> we misuse ReturnAdr. Do you have an idea how this can be achieved? >> (This has nothing to do with this change.) >> >> Best regards, >> Goetz >> >> Thanks, >> Vladimir >> >> On 9/20/13 2:31 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> we use these fields in two situations. >>> >>> We use the constant pool. If the constant pool >>> get's large, we need two instructions to encode the offset >>> into the constant pool, basically looking like this: >>> >>> TOC >>> | >>> exLoadConP_hiNode (Adds upper bits of offset to TOC) >>> | >>> exLoadConP_loNode (Load with immediate offset) >>> >>> When we emit *_hiNode, we get the offset into the constant pool. >>> We can only encode the upper bits, thus we remember the lower bits in >>> the field generated by ins_field_const_toc_offset(int). >>> >>> When we emit the *_loNode, we need access to the *_hiNode to retrieve the >>> remaining bits of the offset. For this, we remember the *_hiNode in field >>> ins_field_const_toc_offset_hi_node(exLoadConP_hiNode*) when we >>> generate the two nodes. >>> >>> To remember data we need to generate relocations we use fields >>> ins_field_load_ic_hi_node(exLoadConL_hiNode*); >>> ins_field_load_ic_node(exLoadConLNode*); >>> ins_field_cbuf_insts_offset(int); >>> We load the inline cache from the constant pool. For this we >>> separate a constant node from the dynamic call node. >>> When we generate the relocation for the inline cache of the call node, >>> we use _load_ic_[hi_]node fields to find the node loading the ic cache. >>> For the virtual_call_Relocation we must know the location of the node >>> loading the constant, to find the constant in the constant pool. >>> The exLoadConL[_hi]Node remembers it's offset in the code cache >>> in field _cbuf_insts_offset. >>> >>> Constants were a performance problem in our port until we used the >>> constant pool (we had one before it was added to HotSpot, but >>> after the instruction section). Further we want separate nodes >>> for each assembler instruction - especially for frequently used >>> nodes as constants and calls - to allow better scheduling. >>> >>> I'm happy to supply more details, or to implement this differently, >>> as long as I can keep the separate nodes. Maybe I have to change >>> the relocation? >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Donnerstag, 19. September 2013 19:25 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. >>> >>> 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 goetz.lindenmaier at sap.com Tue Oct 1 15:54:45 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Oct 2013 22:54:45 +0000 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <524B138F.4020208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D0324B5@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0D03547B@DEWDFEMB12A.global.corp.sap> <524B138F.4020208@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D03693C@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I updated the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ > TraceProfileInterpreter may be not good name. I first thought you implemented bytecodes trace profiling :) > Can you change at least flag's comment to be clear that it is printing? I added some more text. Actually we just copied the text from "ProfileInterpreter" ;) > Can you put under #ifdef CC_INTERP methods in invocationCounter.hpp which are used only by cppInterpreter? Done for the ones I edited. There seem to be several dead methods. Should I clean them up? So far they should be removed by the C++ compiler. I also changed an #ifdef in jvmtiManageCapabilities.cpp from CC_INTERP to ZERO. I already had the correspondent change in arguments.cpp in this webrev, but had missed that one. Best regards and thanks for the review! Goetz In general it is good I think. thanks, Vladimir On 9/30/13 7:21 AM, Lindenmaier, Goetz wrote: > 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 goetz.lindenmaier at sap.com Tue Oct 1 16:25:42 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Oct 2013 23:25:42 +0000 Subject: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. In-Reply-To: <524B13E3.8030007@oracle.com> References: <524B0CE2.2040501@oracle.com> <524B13E3.8030007@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D036978@DEWDFEMB12A.global.corp.sap> Hi Vladimir and Iris, Thanks for the review, I pushed it but -- grrrr -- I forgot to add you as reviewer! I'm sorry, now there is no reviewer. Can we fix this somehow? Or can we roll back the change as we did before? I think Iris, you helped with that, could you have a look, please? I thought jcheck would catch this? I'm sorry for causing additional trouble, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, October 01, 2013 8:27 PM To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev developers' Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Thank you, Goetz I think you described this enough for me to understand changes, You can push these changes now. We don't have closed code for adlc so I think it is safe to push it without JPRT. Thanks, Vladimir On 9/30/13 2:04 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> So you did all this to schedule IC load as separate instruction. Right? > More or less, yes. But not only the IC load. All nodes are broken down > so that they represent a single assembler instruction. (Except for real > big ones as string compare, sync ...). Mostly we use expand, but that's > not always possible. E.g. expanding DecodeN into add+shift early > can cause problems, if the intermediate value which is neither oop nor > narrow oop gets visible to GC. > >> Did you try to use 'expand %{ %}' for call node? We will generate >> separate mach nodes in such case. > I am using expand in several cases, but it does not work for call nodes. > Call nodes are very special. > > Best regards, > Goetz. > > On 9/24/13 6:44 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >>> First, when you say "constant pool" you really mean "constant section" >>> in nmethod. Right? And you want to load constants from it. >> Yes. >> >>> I would like to see you use our implementation of constant loads but it >>> is up to you if it does not affect our shared code. >> I use your functionality to get the constant into the pool, and to get the >> edge to the toc/constanttablebase. But then we split the constant load >> into two nodes, each encoding part of the offset into the pool. >> That's when I need these fields. >> Actually I fixed our nodes as far as possible to use that functionality >> when I first pushed the port into the jdk7 directory. >> >>> To have non-matching CallDynamicJavaDirect__2Node is interesting way to >>> not add new nodes to machnode.hpp. >>> >>> How you keep a live mach node which loads IC (do you have users/edges >>> pointing to it)? And how you scheduling it? And what about live range if >>> it is separated from call site? >> We add the toc/constanttablebase node to the call right after matching. >> Unfortunately constanttablebase can not be used in call nodes, so we >> Walk the graph and add it. We misuse in(TypeFunc::ReturnAdr) >> to point to toc. >> After register allocation we run the lateExpand phase. >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0115_8003850_opto-introduce_phase_lateExpand.patch >> This splits the call node into the individual instructions needed, >> which are two nodes for loading IC, two nodes for loading env ptr >> to r11, two nodes for loading the address, >> one node moving the address to the branch register, and >> the real call. This is then scheduled. The scheduler replaces >> Do_scheduling in output.cpp. >> >> I would like to improve handling constanttablebase with the Call node. There are >> Two problems: you can only use constanttablebase with constant nodes. >> But we need it with Call and storeCM, too. >> The other problem is that you can not add req edges to Call nodes. Therefore >> we misuse ReturnAdr. Do you have an idea how this can be achieved? >> (This has nothing to do with this change.) >> >> Best regards, >> Goetz >> >> Thanks, >> Vladimir >> >> On 9/20/13 2:31 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> we use these fields in two situations. >>> >>> We use the constant pool. If the constant pool >>> get's large, we need two instructions to encode the offset >>> into the constant pool, basically looking like this: >>> >>> TOC >>> | >>> exLoadConP_hiNode (Adds upper bits of offset to TOC) >>> | >>> exLoadConP_loNode (Load with immediate offset) >>> >>> When we emit *_hiNode, we get the offset into the constant pool. >>> We can only encode the upper bits, thus we remember the lower bits in >>> the field generated by ins_field_const_toc_offset(int). >>> >>> When we emit the *_loNode, we need access to the *_hiNode to retrieve the >>> remaining bits of the offset. For this, we remember the *_hiNode in field >>> ins_field_const_toc_offset_hi_node(exLoadConP_hiNode*) when we >>> generate the two nodes. >>> >>> To remember data we need to generate relocations we use fields >>> ins_field_load_ic_hi_node(exLoadConL_hiNode*); >>> ins_field_load_ic_node(exLoadConLNode*); >>> ins_field_cbuf_insts_offset(int); >>> We load the inline cache from the constant pool. For this we >>> separate a constant node from the dynamic call node. >>> When we generate the relocation for the inline cache of the call node, >>> we use _load_ic_[hi_]node fields to find the node loading the ic cache. >>> For the virtual_call_Relocation we must know the location of the node >>> loading the constant, to find the constant in the constant pool. >>> The exLoadConL[_hi]Node remembers it's offset in the code cache >>> in field _cbuf_insts_offset. >>> >>> Constants were a performance problem in our port until we used the >>> constant pool (we had one before it was added to HotSpot, but >>> after the instruction section). Further we want separate nodes >>> for each assembler instruction - especially for frequently used >>> nodes as constants and calls - to allow better scheduling. >>> >>> I'm happy to supply more details, or to implement this differently, >>> as long as I can keep the separate nodes. Maybe I have to change >>> the relocation? >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Donnerstag, 19. September 2013 19:25 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. >>> >>> 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 mikael.vidstedt at oracle.com Tue Oct 1 17:22:34 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 01 Oct 2013 17:22:34 -0700 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions In-Reply-To: References: <524A16C0.4080606@oracle.com> Message-ID: <524B674A.8080201@oracle.com> Coleen/Christian/Chris/Dmitry - Thanks for the reviews. Since this is only relevant on pre-1.4 JDKs I actually really think nobody depends on this. I noticed that I needed one small additional change in nativeLookup.cpp - the struct is iterated over in the function just below (lookup_special_native) and the start index was previously initialized to 2 for jdk1.4+, skipping the first two entries in the array. With that change in place everything works as expected. I uploaded a webrev with that change included for the curious: http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.01/webrev/ Cheers, Mikael On 2013-09-30 18:27, Christian Thalinger wrote: > 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 >> From vladimir.danushevsky at oracle.com Tue Oct 1 17:35:40 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Wed, 02 Oct 2013 00:35:40 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20131002003554.6A64562C83@hg.openjdk.java.net> Changeset: 33224bdb3199 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/33224bdb3199 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 460823b46c3d Author: bpittore Date: 2013-08-28 14:44 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/460823b46c3d 8023580: Add jtreg test for 8004051 and 8005722 Summary: Tests checks an assertion dealing with the number of args passed in registers Reviewed-by: mseledtsov, kvn + test/compiler/8004051/Test8004051.java From vladimir.kozlov at oracle.com Tue Oct 1 19:30:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Oct 2013 19:30:24 -0700 Subject: RFR (L): 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D03693C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D0324B5@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0D03547B@DEWDFEMB12A.global.corp.sap> <524B138F.4020208@oracle.com> <4295855A5C1DE049A61835A1887419CC0D03693C@DEWDFEMB12A.global.corp.sap> Message-ID: <524B8540.2080602@oracle.com> Yes, this looks good. I think we should use JPRT this time to verify that this and previous changeset are clean. Anyway we need to wait when Iris resolves the problem with last changeset. Thanks, Vladimir On 10/1/13 3:54 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I updated the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8024468-profile/ > >> TraceProfileInterpreter may be not good name. I first thought you implemented bytecodes trace profiling :) >> Can you change at least flag's comment to be clear that it is printing? > I added some more text. Actually we just copied the text from "ProfileInterpreter" ;) > >> Can you put under #ifdef CC_INTERP methods in invocationCounter.hpp which are used only by cppInterpreter? > Done for the ones I edited. There seem to be several dead methods. > Should I clean them up? So far they should be removed by the > C++ compiler. > > I also changed an #ifdef in jvmtiManageCapabilities.cpp from > CC_INTERP to ZERO. I already had the correspondent change in > arguments.cpp in this webrev, but had missed that one. > > Best regards and thanks for the review! > Goetz > > > > In general it is good I think. > > thanks, > Vladimir > > On 9/30/13 7:21 AM, Lindenmaier, Goetz wrote: >> 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 john.r.rose at oracle.com Tue Oct 1 23:37:20 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 23:37:20 -0700 Subject: CFV: new hsx committer: David Chase Message-ID: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. Since November of 2012, David has contributed widely to the HotSpot code base. Here are his commits, more recent first: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation 8017578: Hotspot compilation error with latest Studio compiler 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 8002160: Compilation issue with adlc using latest SunStudio compilers 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit 6443505: Ideal() function for CmpLTMask 7104565: trim jprt build targets 8007776: Test6852078.java timeouts 7102300: performance warnings cause results diff failure in Test6890943 8008180: Several tests in compiler/5091921 need more time to run 8007402: Code cleanup to remove Parfait false positive 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray 8006500: compiler/8004741/Test8004741.java fails intermediately 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink 8010913: compiler/6863420 often exceeds timeout 8005821: C2: -XX:+PrintIntrinsics is broken 8006204: please JTREGify test/compiler/7190310/Test7190310.java 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. Votes are due by Tuesday, October 15. Only current hsx Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [2]. ? John Rose [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Wed Oct 2 00:04:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Oct 2013 17:04:48 +1000 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524BC590.10104@oracle.com> Vote: yes :) David On 2/10/2013 4:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From staffan.larsen at oracle.com Wed Oct 2 00:09:41 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Oct 2013 09:09:41 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: Vote: yes. /Staffan On 2 okt 2013, at 08:37, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From roland.westrelin at oracle.com Wed Oct 2 00:33:01 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Oct 2013 09:33:01 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <4BB224A9-9E80-44AF-9411-3DADD6BBA6C8@oracle.com> Vote: yes. Roland. From stefan.karlsson at oracle.com Wed Oct 2 01:06:54 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 02 Oct 2013 10:06:54 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524BD41E.60701@oracle.com> Vote: yes StefanK On 10/02/2013 08:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From rickard.backman at oracle.com Wed Oct 2 01:03:01 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 2 Oct 2013 10:03:01 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <044B77B0-3284-42AE-8462-9BCE13A1FFFE@oracle.com> Vote: yes /R On Oct 2, 2013, at 8:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From vladimir.x.ivanov at oracle.com Wed Oct 2 01:04:17 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 02 Oct 2013 12:04:17 +0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524BD381.8030303@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 10/2/13 10:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From niclas.adlertz at oracle.com Wed Oct 2 01:12:35 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 02 Oct 2013 10:12:35 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524BD573.6060406@oracle.com> Vote: Yes Kind Regards, Niclas Adlertz On 2013-10-02 08:37, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From frederic.parain at oracle.com Wed Oct 2 02:08:53 2013 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 02 Oct 2013 11:08:53 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524BE2A5.9030606@oracle.com> Vote: yes Fred On 10/02/2013 08:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From igor.veresov at oracle.com Wed Oct 2 04:47:04 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Oct 2013 15:47:04 +0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: Vote: yes igor On Oct 2, 2013, at 10:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From bengt.rutisson at oracle.com Wed Oct 2 04:51:21 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 02 Oct 2013 13:51:21 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C08B9.2050606@oracle.com> Vote: yes Bengt On 10/2/13 8:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From karen.kinnear at oracle.com Wed Oct 2 04:53:59 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 2 Oct 2013 07:53:59 -0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <3D2D36A0-B9B3-4D12-A902-B8B575518360@oracle.com> vote: yes thanks, Karen On Oct 2, 2013, at 2:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From zhengyu.gu at oracle.com Wed Oct 2 05:05:08 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 02 Oct 2013 08:05:08 -0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C0BF4.5050802@oracle.com> Vote: yes -Zhengyu On 10/2/2013 2:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From mikael.gerdin at oracle.com Wed Oct 2 05:28:54 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 02 Oct 2013 14:28:54 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking Message-ID: <524C1186.5070105@oracle.com> Hi Please review my fix for the issue discussed in the "G1 question: concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing list. I'd like someone from the compiler (and runtime? the interpreter uses macroAssembler_*, right?) teams to at least look at the changes to: macroAssembler_*.cpp c1_Runtime_*.cpp graphKit.cpp Problem description: G1 has a race where the concurrent refinement thread may miss object references in a dirty card. The problem arises if the CPU re-orders the load of the old card value (which G1 checks to determine if it can skip the barrier) before the store to the actual object. If that occurs the concurrent refinement thread may have set the card to "clean" and proceeded to scan the card but the java thread may have seen the "dirty" value and skipped the post barrier. Suggested fix: * Add a memory fence between the store to a java object and the reading of the previous card value. * Modify the code for handling young regions so that all writes to young regions can skip the fence (since it will never be needed for such writes). This introduces a new value in the card table for G1 which indicates a young region. Performance impact: * This fix has a negative throughput performance impact of 1-1.5% (tested on x86-AMD x86-Intel and SPARC). * We may want to try to get rid of this race at some point by redesigning G1's post barrier but there is not enough time to do that for JDK8. Performance numbers for x86 platforms can be seen here: http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt Unfortunately the JIRA issue is not externally visible, but the major parts of the discussions about this are present in the mailing list thread. The bug mostly contains my analysis of the crashes which seems to have been caused by this bug. Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 From coleen.phillimore at oracle.com Wed Oct 2 05:47:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 02 Oct 2013 08:47:15 -0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C15D3.6080302@oracle.com> Vote: yes On 10/2/2013 2:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From thomas.schatzl at oracle.com Wed Oct 2 05:50:56 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Oct 2013 14:50:56 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <1380718256.2710.73.camel@cirrus> Vote: yes On Tue, 2013-10-01 at 23:37 -0700, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From christian.tornqvist at oracle.com Wed Oct 2 05:51:21 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 2 Oct 2013 08:51:21 -0400 Subject: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <01e801cebf6e$188f5f00$49ae1d00$@oracle.com> Vote: yes -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of John Rose Sent: Wednesday, October 2, 2013 2:37 AM To: hotspot-dev at openjdk.java.net developers Subject: CFV: new hsx committer: David Chase I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. Since November of 2012, David has contributed widely to the HotSpot code base. Here are his commits, more recent first: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation 8017578: Hotspot compilation error with latest Studio compiler 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 8002160: Compilation issue with adlc using latest SunStudio compilers 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit 6443505: Ideal() function for CmpLTMask 7104565: trim jprt build targets 8007776: Test6852078.java timeouts 7102300: performance warnings cause results diff failure in Test6890943 8008180: Several tests in compiler/5091921 need more time to run 8007402: Code cleanup to remove Parfait false positive 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray 8006500: compiler/8004741/Test8004741.java fails intermediately 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink 8010913: compiler/6863420 often exceeds timeout 8005821: C2: -XX:+PrintIntrinsics is broken 8006204: please JTREGify test/compiler/7190310/Test7190310.java 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. Votes are due by Tuesday, October 15. Only current hsx Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [2]. - John Rose [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Wed Oct 2 06:45:23 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 02 Oct 2013 07:45:23 -0600 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C2373.4000402@oracle.com> Vote: yes Dan On 10/2/13 12:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From goetz.lindenmaier at sap.com Wed Oct 2 06:49:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Oct 2013 13:49:12 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. Message-ID: <4295855A5C1DE049A61835A1887419CC0D036BFF@DEWDFEMB12A.global.corp.sap> Hi, we extended C2 by what we call lateExpand. LateExpand expands nodes after register allocation. http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ Some nodes can not be expanded during matching. E.g., register allocation might not be able to deal with the resulting pattern. To allow better scheduling in such cases, we introduce lateExpand which runs after register allocation. Whether and how nodes are expanded is specified in the ad-file. See block.cpp for a detailed documentation. We use this for some nodes on ppc, and extensively on ia64. For an example, see the webrev. We added some utility functions in node.hpp and block.hpp used by PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, MachConstantBaseNode gets the two new functions, as we need to late expand it. To skip the walk over the IR if no lateExpand is needed, we use Matcher::require_late_expand set in the ad file. This ends up in ad_.cpp, thus can not be evaluated by the C++ compiler. If you agree, I would use a "const bool EnableLateExpand" in globalDefinitions_.hpp. (There is no suitable c2__.hpp file). We allready mailed a webrev with this change after last year's JavaOne, but there was no discussion on it. Again, this change is 'L', but the code is not used on other platforms than PPC64 (so far). So the impact on those platforms should be minimal. Please review and test this change. Thanks and best regards, Goetz. From igor.veresov at oracle.com Wed Oct 2 07:39:53 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Oct 2013 18:39:53 +0400 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: <6CE28C08-6DB9-4632-83ED-1578988E3A86@oracle.com> Looks good! igor On Oct 2, 2013, at 4:28 PM, Mikael Gerdin wrote: > Hi > > Please review my fix for the issue discussed in the "G1 question: concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing list. > > I'd like someone from the compiler (and runtime? the interpreter uses macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may miss object references in a dirty card. > The problem arises if the CPU re-orders the load of the old card value (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set the card to "clean" and proceeded to scan the card but the java thread may have seen the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and the reading of the previous card value. > * Modify the code for handling young regions so that all writes to young regions can skip the fence (since it will never be needed for such writes). This introduces a new value in the card table for G1 which indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of 1-1.5% (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by redesigning G1's post barrier but there is not enough time to do that for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt > > Unfortunately the JIRA issue is not externally visible, but the major parts of the discussions about this are present in the mailing list thread. The bug mostly contains my analysis of the crashes which seems to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 > From bharadwaj.yadavalli at oracle.com Wed Oct 2 07:53:07 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 02 Oct 2013 10:53:07 -0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C3353.2040809@oracle.com> Vote: yes Bharadwaj On 10/2/2013 2:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. <...> From thomas.schatzl at oracle.com Wed Oct 2 08:55:33 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Oct 2013 17:55:33 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: <1380729333.2710.82.camel@cirrus> Hi, On Wed, 2013-10-02 at 14:28 +0200, Mikael Gerdin wrote: > Hi > > Please review my fix for the issue discussed in the "G1 question: > concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing > list. > > I'd like someone from the compiler (and runtime? the interpreter uses > macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set the card to > "clean" and proceeded to scan the card but the java thread may have seen > the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and the reading > of the previous card value. > * Modify the code for handling young regions so that all writes to young > regions can skip the fence (since it will never be needed for such > writes). This introduces a new value in the card table for G1 which > indicates a young region. Looks good. Thomas From morris.meyer at oracle.com Wed Oct 2 08:56:33 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 02 Oct 2013 11:56:33 -0400 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C4231.30404@oracle.com> Vote: yes On 10/2/13, 2:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From vladimir.kozlov at oracle.com Wed Oct 2 09:12:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Oct 2013 09:12:31 -0700 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C45EF.3070805@oracle.com> Vote: yes Vladimir On 10/1/13 11:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From mikael.gerdin at oracle.com Wed Oct 2 09:14:45 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 02 Oct 2013 18:14:45 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <6CE28C08-6DB9-4632-83ED-1578988E3A86@oracle.com> References: <524C1186.5070105@oracle.com> <6CE28C08-6DB9-4632-83ED-1578988E3A86@oracle.com> Message-ID: <524C4675.5000207@oracle.com> On 2013-10-02 16:39, Igor Veresov wrote: > Looks good! Thanks, Igor! /Mikael > > igor > > On Oct 2, 2013, at 4:28 PM, Mikael Gerdin wrote: > >> Hi >> >> Please review my fix for the issue discussed in the "G1 question: concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing list. >> >> I'd like someone from the compiler (and runtime? the interpreter uses macroAssembler_*, right?) teams to at least look at the changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may miss object references in a dirty card. >> The problem arises if the CPU re-orders the load of the old card value (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set the card to "clean" and proceeded to scan the card but the java thread may have seen the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and the reading of the previous card value. >> * Modify the code for handling young regions so that all writes to young regions can skip the fence (since it will never be needed for such writes). This introduces a new value in the card table for G1 which indicates a young region. >> >> Performance impact: >> * This fix has a negative throughput performance impact of 1-1.5% (tested on x86-AMD x86-Intel and SPARC). >> * We may want to try to get rid of this race at some point by redesigning G1's post barrier but there is not enough time to do that for JDK8. >> >> Performance numbers for x86 platforms can be seen here: >> http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt >> >> Unfortunately the JIRA issue is not externally visible, but the major parts of the discussions about this are present in the mailing list thread. The bug mostly contains my analysis of the crashes which seems to have been caused by this bug. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 >> > From mikael.gerdin at oracle.com Wed Oct 2 09:15:06 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 02 Oct 2013 18:15:06 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <1380729333.2710.82.camel@cirrus> References: <524C1186.5070105@oracle.com> <1380729333.2710.82.camel@cirrus> Message-ID: <524C468A.1080101@oracle.com> On 2013-10-02 17:55, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-10-02 at 14:28 +0200, Mikael Gerdin wrote: >> Hi >> >> Please review my fix for the issue discussed in the "G1 question: >> concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing >> list. >> >> I'd like someone from the compiler (and runtime? the interpreter uses >> macroAssembler_*, right?) teams to at least look at the changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may miss object >> references in a dirty card. >> The problem arises if the CPU re-orders the load of the old card value >> (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set the card to >> "clean" and proceeded to scan the card but the java thread may have seen >> the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and the reading >> of the previous card value. >> * Modify the code for handling young regions so that all writes to young >> regions can skip the fence (since it will never be needed for such >> writes). This introduces a new value in the card table for G1 which >> indicates a young region. > > Looks good. Thanks Thomas! /Mikael > > Thomas > > From tao.mao at oracle.com Wed Oct 2 09:37:33 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 02 Oct 2013 09:37:33 -0700 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C4BCD.3070106@oracle.com> Vote: yes Best, Tao On 10/1/13 11:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes()< (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From serguei.spitsyn at oracle.com Wed Oct 2 10:33:28 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 02 Oct 2013 10:33:28 -0700 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524C58E8.401@oracle.com> Vote: yes On 10/1/13 11:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From vladimir.x.ivanov at oracle.com Wed Oct 2 12:18:47 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 02 Oct 2013 23:18:47 +0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) Message-ID: <524C7197.7060603@oracle.com> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ 1 line changed: 0 ins; 0 del; 1 mod Warnings are mostly ignored during testing - tests rarely looks at VM output. But this check may reveal a serious problem which is hard to diagnose (possible deadlock between VM thread & suspended Java thread). If it is converted to an assert, the crash log will contain enough information to find the place where VM lock is acquired, since the check is performed on a thread which hold the lock. The change doesn't affect product - the check is guarded by #ifdef ASSERT. Inspired by JDK-8023461 [1] Testing: JPRT, VM testbase. Reviewed-by: ? Thanks! Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8023461 From igor.veresov at oracle.com Wed Oct 2 12:52:48 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Oct 2013 23:52:48 +0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524C7197.7060603@oracle.com> References: <524C7197.7060603@oracle.com> Message-ID: <65F47E08-9FB4-4585-80B4-52875310DDAD@oracle.com> Looks good. igor On Oct 2, 2013, at 11:18 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ > 1 line changed: 0 ins; 0 del; 1 mod > > Warnings are mostly ignored during testing - tests rarely looks at VM output. But this check may reveal a serious problem which is hard to diagnose (possible deadlock between VM thread & suspended Java thread). > > If it is converted to an assert, the crash log will contain enough information to find the place where VM lock is acquired, since the check is performed on a thread which hold the lock. > > The change doesn't affect product - the check is guarded by #ifdef ASSERT. > > Inspired by JDK-8023461 [1] > > Testing: JPRT, VM testbase. > > Reviewed-by: ? > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8023461 From vladimir.x.ivanov at oracle.com Wed Oct 2 12:56:20 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 02 Oct 2013 23:56:20 +0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <65F47E08-9FB4-4585-80B4-52875310DDAD@oracle.com> References: <524C7197.7060603@oracle.com> <65F47E08-9FB4-4585-80B4-52875310DDAD@oracle.com> Message-ID: <524C7A64.8030207@oracle.com> Thank you, Igor. Best regards, Vladimir Ivanov On 10/2/13 11:52 PM, Igor Veresov wrote: > Looks good. > > igor > > On Oct 2, 2013, at 11:18 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ >> 1 line changed: 0 ins; 0 del; 1 mod >> >> Warnings are mostly ignored during testing - tests rarely looks at VM output. But this check may reveal a serious problem which is hard to diagnose (possible deadlock between VM thread & suspended Java thread). >> >> If it is converted to an assert, the crash log will contain enough information to find the place where VM lock is acquired, since the check is performed on a thread which hold the lock. >> >> The change doesn't affect product - the check is guarded by #ifdef ASSERT. >> >> Inspired by JDK-8023461 [1] >> >> Testing: JPRT, VM testbase. >> >> Reviewed-by: ? >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8023461 > From calvin.cheung at oracle.com Wed Oct 2 14:13:46 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Wed, 02 Oct 2013 21:13:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20131002211407.246A562CBF@hg.openjdk.java.net> Changeset: 899ecf76b570 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/899ecf76b570 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 5b1191bf0b4b Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5b1191bf0b4b 8024677: [TESTBUG] Move tests for classes in /testlibrary Summary: Moved the tests to /testlibrary_tests and updated TEST.groups Reviewed-by: dholmes, sla ! test/TEST.groups - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java + test/testlibrary_tests/AssertsTest.java + test/testlibrary_tests/OutputAnalyzerReportingTest.java + test/testlibrary_tests/OutputAnalyzerTest.java Changeset: c1fbf21c7397 Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c1fbf21c7397 8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures Summary: Added methods for 32bit, arm, ppc, x64 and x86 Reviewed-by: zgu, hseigel, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 190899198332 Author: hseigel Date: 2013-09-26 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/190899198332 7195622: CheckUnhandledOops has limited usefulness now Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms. Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a5ac0873476c Author: zgu Date: 2013-09-27 10:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a5ac0873476c Merge ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/31f0118ea584 Merge From iris.clark at oracle.com Wed Oct 2 14:23:41 2013 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 2 Oct 2013 14:23:41 -0700 (PDT) Subject: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D036978@DEWDFEMB12A.global.corp.sap> References: <524B0CE2.2040501@oracle.com> <524B13E3.8030007@oracle.com> <4295855A5C1DE049A61835A1887419CC0D036978@DEWDFEMB12A.global.corp.sap> Message-ID: Hi, Goetz. I've rolled back the problematic changeset. You should be set. I'm not quite sure why jcheck did not detect this problem and am investigating in a separate thread. Thanks, iris -----Original Message----- From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] Sent: Tuesday, October 01, 2013 4:26 PM To: Vladimir Kozlov; Iris Clark (iris.clark at oracle.com) Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: RE: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Hi Vladimir and Iris, Thanks for the review, I pushed it but -- grrrr -- I forgot to add you as reviewer! I'm sorry, now there is no reviewer. Can we fix this somehow? Or can we roll back the change as we did before? I think Iris, you helped with that, could you have a look, please? I thought jcheck would catch this? I'm sorry for causing additional trouble, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, October 01, 2013 8:27 PM To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev developers' Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Thank you, Goetz I think you described this enough for me to understand changes, You can push these changes now. We don't have closed code for adlc so I think it is safe to push it without JPRT. Thanks, Vladimir On 9/30/13 2:04 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> So you did all this to schedule IC load as separate instruction. Right? > More or less, yes. But not only the IC load. All nodes are broken > down so that they represent a single assembler instruction. (Except > for real big ones as string compare, sync ...). Mostly we use expand, > but that's not always possible. E.g. expanding DecodeN into add+shift > early can cause problems, if the intermediate value which is neither > oop nor narrow oop gets visible to GC. > >> Did you try to use 'expand %{ %}' for call node? We will generate >> separate mach nodes in such case. > I am using expand in several cases, but it does not work for call nodes. > Call nodes are very special. > > Best regards, > Goetz. > > On 9/24/13 6:44 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >>> First, when you say "constant pool" you really mean "constant section" >>> in nmethod. Right? And you want to load constants from it. >> Yes. >> >>> I would like to see you use our implementation of constant loads but >>> it is up to you if it does not affect our shared code. >> I use your functionality to get the constant into the pool, and to >> get the edge to the toc/constanttablebase. But then we split the >> constant load into two nodes, each encoding part of the offset into the pool. >> That's when I need these fields. >> Actually I fixed our nodes as far as possible to use that >> functionality when I first pushed the port into the jdk7 directory. >> >>> To have non-matching CallDynamicJavaDirect__2Node is interesting way >>> to not add new nodes to machnode.hpp. >>> >>> How you keep a live mach node which loads IC (do you have >>> users/edges pointing to it)? And how you scheduling it? And what >>> about live range if it is separated from call site? >> We add the toc/constanttablebase node to the call right after matching. >> Unfortunately constanttablebase can not be used in call nodes, so we >> Walk the graph and add it. We misuse in(TypeFunc::ReturnAdr) to >> point to toc. >> After register allocation we run the lateExpand phase. >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92 >> d/ppc_patches/0115_8003850_opto-introduce_phase_lateExpand.patch >> This splits the call node into the individual instructions needed, >> which are two nodes for loading IC, two nodes for loading env ptr to >> r11, two nodes for loading the address, one node moving the address >> to the branch register, and the real call. This is then scheduled. >> The scheduler replaces Do_scheduling in output.cpp. >> >> I would like to improve handling constanttablebase with the Call >> node. There are Two problems: you can only use constanttablebase with constant nodes. >> But we need it with Call and storeCM, too. >> The other problem is that you can not add req edges to Call nodes. >> Therefore we misuse ReturnAdr. Do you have an idea how this can be achieved? >> (This has nothing to do with this change.) >> >> Best regards, >> Goetz >> >> Thanks, >> Vladimir >> >> On 9/20/13 2:31 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> we use these fields in two situations. >>> >>> We use the constant pool. If the constant pool get's large, we need >>> two instructions to encode the offset into the constant pool, >>> basically looking like this: >>> >>> TOC >>> | >>> exLoadConP_hiNode (Adds upper bits of offset to TOC) >>> | >>> exLoadConP_loNode (Load with immediate offset) >>> >>> When we emit *_hiNode, we get the offset into the constant pool. >>> We can only encode the upper bits, thus we remember the lower bits >>> in the field generated by ins_field_const_toc_offset(int). >>> >>> When we emit the *_loNode, we need access to the *_hiNode to >>> retrieve the remaining bits of the offset. For this, we remember the >>> *_hiNode in field >>> ins_field_const_toc_offset_hi_node(exLoadConP_hiNode*) when we >>> generate the two nodes. >>> >>> To remember data we need to generate relocations we use fields >>> ins_field_load_ic_hi_node(exLoadConL_hiNode*); >>> ins_field_load_ic_node(exLoadConLNode*); >>> ins_field_cbuf_insts_offset(int); We load the inline cache from >>> the constant pool. For this we separate a constant node from the >>> dynamic call node. >>> When we generate the relocation for the inline cache of the call >>> node, we use _load_ic_[hi_]node fields to find the node loading the ic cache. >>> For the virtual_call_Relocation we must know the location of the >>> node loading the constant, to find the constant in the constant pool. >>> The exLoadConL[_hi]Node remembers it's offset in the code cache in >>> field _cbuf_insts_offset. >>> >>> Constants were a performance problem in our port until we used the >>> constant pool (we had one before it was added to HotSpot, but after >>> the instruction section). Further we want separate nodes for each >>> assembler instruction - especially for frequently used nodes as >>> constants and calls - to allow better scheduling. >>> >>> I'm happy to supply more details, or to implement this differently, >>> as long as I can keep the separate nodes. Maybe I have to change >>> the relocation? >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Donnerstag, 19. September 2013 19:25 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. >>> >>> 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/e6d09cebf >>>> 92d/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 goetz.lindenmaier at sap.com Wed Oct 2 14:37:37 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Oct 2013 21:37:37 +0000 Subject: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. In-Reply-To: References: <524B0CE2.2040501@oracle.com> <524B13E3.8030007@oracle.com> <4295855A5C1DE049A61835A1887419CC0D036978@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0D037D99@DEWDFEMB12A.global.corp.sap> Hi Iris, thank you for the help! I'll push the change once more. Sorry for the trouble, Goetz. -----Original Message----- From: Iris Clark [mailto:iris.clark at oracle.com] Sent: Wednesday, October 02, 2013 11:24 PM To: Lindenmaier, Goetz; Vladimir Kozlov Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: RE: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Hi, Goetz. I've rolled back the problematic changeset. You should be set. I'm not quite sure why jcheck did not detect this problem and am investigating in a separate thread. Thanks, iris -----Original Message----- From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] Sent: Tuesday, October 01, 2013 4:26 PM To: Vladimir Kozlov; Iris Clark (iris.clark at oracle.com) Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: RE: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Hi Vladimir and Iris, Thanks for the review, I pushed it but -- grrrr -- I forgot to add you as reviewer! I'm sorry, now there is no reviewer. Can we fix this somehow? Or can we roll back the change as we did before? I think Iris, you helped with that, could you have a look, please? I thought jcheck would catch this? I'm sorry for causing additional trouble, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, October 01, 2013 8:27 PM To: Lindenmaier, Goetz Cc: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev developers' Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Thank you, Goetz I think you described this enough for me to understand changes, You can push these changes now. We don't have closed code for adlc so I think it is safe to push it without JPRT. Thanks, Vladimir On 9/30/13 2:04 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> So you did all this to schedule IC load as separate instruction. Right? > More or less, yes. But not only the IC load. All nodes are broken > down so that they represent a single assembler instruction. (Except > for real big ones as string compare, sync ...). Mostly we use expand, > but that's not always possible. E.g. expanding DecodeN into add+shift > early can cause problems, if the intermediate value which is neither > oop nor narrow oop gets visible to GC. > >> Did you try to use 'expand %{ %}' for call node? We will generate >> separate mach nodes in such case. > I am using expand in several cases, but it does not work for call nodes. > Call nodes are very special. > > Best regards, > Goetz. > > On 9/24/13 6:44 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >>> First, when you say "constant pool" you really mean "constant section" >>> in nmethod. Right? And you want to load constants from it. >> Yes. >> >>> I would like to see you use our implementation of constant loads but >>> it is up to you if it does not affect our shared code. >> I use your functionality to get the constant into the pool, and to >> get the edge to the toc/constanttablebase. But then we split the >> constant load into two nodes, each encoding part of the offset into the pool. >> That's when I need these fields. >> Actually I fixed our nodes as far as possible to use that >> functionality when I first pushed the port into the jdk7 directory. >> >>> To have non-matching CallDynamicJavaDirect__2Node is interesting way >>> to not add new nodes to machnode.hpp. >>> >>> How you keep a live mach node which loads IC (do you have >>> users/edges pointing to it)? And how you scheduling it? And what >>> about live range if it is separated from call site? >> We add the toc/constanttablebase node to the call right after matching. >> Unfortunately constanttablebase can not be used in call nodes, so we >> Walk the graph and add it. We misuse in(TypeFunc::ReturnAdr) to >> point to toc. >> After register allocation we run the lateExpand phase. >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92 >> d/ppc_patches/0115_8003850_opto-introduce_phase_lateExpand.patch >> This splits the call node into the individual instructions needed, >> which are two nodes for loading IC, two nodes for loading env ptr to >> r11, two nodes for loading the address, one node moving the address >> to the branch register, and the real call. This is then scheduled. >> The scheduler replaces Do_scheduling in output.cpp. >> >> I would like to improve handling constanttablebase with the Call >> node. There are Two problems: you can only use constanttablebase with constant nodes. >> But we need it with Call and storeCM, too. >> The other problem is that you can not add req edges to Call nodes. >> Therefore we misuse ReturnAdr. Do you have an idea how this can be achieved? >> (This has nothing to do with this change.) >> >> Best regards, >> Goetz >> >> Thanks, >> Vladimir >> >> On 9/20/13 2:31 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> we use these fields in two situations. >>> >>> We use the constant pool. If the constant pool get's large, we need >>> two instructions to encode the offset into the constant pool, >>> basically looking like this: >>> >>> TOC >>> | >>> exLoadConP_hiNode (Adds upper bits of offset to TOC) >>> | >>> exLoadConP_loNode (Load with immediate offset) >>> >>> When we emit *_hiNode, we get the offset into the constant pool. >>> We can only encode the upper bits, thus we remember the lower bits >>> in the field generated by ins_field_const_toc_offset(int). >>> >>> When we emit the *_loNode, we need access to the *_hiNode to >>> retrieve the remaining bits of the offset. For this, we remember the >>> *_hiNode in field >>> ins_field_const_toc_offset_hi_node(exLoadConP_hiNode*) when we >>> generate the two nodes. >>> >>> To remember data we need to generate relocations we use fields >>> ins_field_load_ic_hi_node(exLoadConL_hiNode*); >>> ins_field_load_ic_node(exLoadConLNode*); >>> ins_field_cbuf_insts_offset(int); We load the inline cache from >>> the constant pool. For this we separate a constant node from the >>> dynamic call node. >>> When we generate the relocation for the inline cache of the call >>> node, we use _load_ic_[hi_]node fields to find the node loading the ic cache. >>> For the virtual_call_Relocation we must know the location of the >>> node loading the constant, to find the constant in the constant pool. >>> The exLoadConL[_hi]Node remembers it's offset in the code cache in >>> field _cbuf_insts_offset. >>> >>> Constants were a performance problem in our port until we used the >>> constant pool (we had one before it was added to HotSpot, but after >>> the instruction section). Further we want separate nodes for each >>> assembler instruction - especially for frequently used nodes as >>> constants and calls - to allow better scheduling. >>> >>> I'm happy to supply more details, or to implement this differently, >>> as long as I can keep the separate nodes. Maybe I have to change >>> the relocation? >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Donnerstag, 19. September 2013 19:25 >>> To: Lindenmaier, Goetz >>> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. >>> >>> 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/e6d09cebf >>>> 92d/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 bengt.rutisson at oracle.com Wed Oct 2 21:54:46 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 03 Oct 2013 06:54:46 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: <524CF896.9030807@oracle.com> Hi Mikael, My knowledge about the compiler and interpreter code is not enough to formally review it, but as far as I can tell it looks good. The GC code changes looks good. Reviewed. Thanks for doing such a good job with this difficult change! Bengt On 10/2/13 2:28 PM, Mikael Gerdin wrote: > Hi > > Please review my fix for the issue discussed in the "G1 question: > concurrent cleaning of dirty cards" thread on the hotspot-gc-dev > mailing list. > > I'd like someone from the compiler (and runtime? the interpreter uses > macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set the card > to "clean" and proceeded to scan the card but the java thread may have > seen the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and the > reading of the previous card value. > * Modify the code for handling young regions so that all writes to > young regions can skip the fence (since it will never be needed for > such writes). This introduces a new value in the card table for G1 > which indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of 1-1.5% > (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by > redesigning G1's post barrier but there is not enough time to do that > for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt > > Unfortunately the JIRA issue is not externally visible, but the major > parts of the discussions about this are present in the mailing list > thread. The bug mostly contains my analysis of the crashes which seems > to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 > From alejandro.murillo at oracle.com Wed Oct 2 22:07:30 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 02 Oct 2013 23:07:30 -0600 Subject: Code review request 8025861: Set minor version for hotspot in 7u60 to 60 and build number to b01 Message-ID: <524CFB92.3000601@oracle.com> Can I get a quick review of this change: 8025861 : Set minor version for hotspot in 7u60 to 60 and build number to b01 http://cr.openjdk.java.net/~amurillo/7u60/8025861_webrev/ Thanks -- Alejandro From stefan.karlsson at oracle.com Wed Oct 2 22:36:54 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 03 Oct 2013 07:36:54 +0200 Subject: Code review request 8025861: Set minor version for hotspot in 7u60 to 60 and build number to b01 In-Reply-To: <524CFB92.3000601@oracle.com> References: <524CFB92.3000601@oracle.com> Message-ID: <524D0276.2080309@oracle.com> On 10/3/13 7:07 AM, Alejandro E Murillo wrote: > > Can I get a quick review of this change: > > 8025861 : Set minor > version for hotspot in 7u60 to 60 and build number to b01 > > > http://cr.openjdk.java.net/~amurillo/7u60/8025861_webrev/ It seems to do what you intended. =) Reviewed. StefanK > > Thanks > From staffan.larsen at oracle.com Wed Oct 2 23:30:24 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Oct 2013 08:30:24 +0200 Subject: Code review request 8025861: Set minor version for hotspot in 7u60 to 60 and build number to b01 In-Reply-To: <524CFB92.3000601@oracle.com> References: <524CFB92.3000601@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 3 okt 2013, at 07:07, Alejandro E Murillo wrote: > > Can I get a quick review of this change: > > 8025861 : Set minor version for hotspot in 7u60 to 60 and build number to b01 > > > http://cr.openjdk.java.net/~amurillo/7u60/8025861_webrev/ > > Thanks > > -- > Alejandro > From roland.westrelin at oracle.com Thu Oct 3 01:11:31 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Oct 2013 10:11:31 +0200 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524C7197.7060603@oracle.com> References: <524C7197.7060603@oracle.com> Message-ID: > http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Thu Oct 3 02:19:38 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Oct 2013 11:19:38 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: > I'd like someone from the compiler (and runtime? the interpreter uses macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp That looks good to me. Maybe a comment that says you're using Op_MemBarVolatile because you need a StoreLoad. Roland. From vladimir.x.ivanov at oracle.com Thu Oct 3 02:52:24 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 13:52:24 +0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: References: <524C7197.7060603@oracle.com> Message-ID: <524D3E58.9000307@oracle.com> Thank you, Roland. Best regards, Vladimir Ivanov On 10/3/13 12:11 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ > > That looks good to me. > > Roland. > From stefan.johansson at oracle.com Thu Oct 3 04:19:10 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 03 Oct 2013 13:19:10 +0200 Subject: RFR: 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Message-ID: <524D52AE.7050605@oracle.com> Hi, Please review this fix for: https://bugs.openjdk.java.net/browse/JDK-8025661 Webrev: http://cr.openjdk.java.net/~sjohanss/8025661/webrev.00/ Summary: The parsing of -Xminf and -Xmaxf has been done with atof() which doesn't detect errors. If using strtod() instead it's possible verify whether the whole input was parsed or not. Also added a test to verify that we detect ill-formed input after the change. Thanks, StefanJ From bengt.rutisson at oracle.com Thu Oct 3 04:43:19 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 03 Oct 2013 13:43:19 +0200 Subject: RFR: 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 In-Reply-To: <524D52AE.7050605@oracle.com> References: <524D52AE.7050605@oracle.com> Message-ID: <524D5857.7020201@oracle.com> Hi Stefan, Looks good! One minor nit. In the test you use "NAN" as something that should not be parsed as a number. Maybe it would be clearer to use something that is clearly not related to numbers, such as "garbage" or "invalid input". Bengt On 10/3/13 1:19 PM, Stefan Johansson wrote: > Hi, > > Please review this fix for: > https://bugs.openjdk.java.net/browse/JDK-8025661 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8025661/webrev.00/ > > Summary: > The parsing of -Xminf and -Xmaxf has been done with atof() which > doesn't detect errors. If using strtod() instead it's possible verify > whether the whole input was parsed or not. > > Also added a test to verify that we detect ill-formed input after the > change. > > Thanks, > StefanJ From per.liden at oracle.com Thu Oct 3 04:44:42 2013 From: per.liden at oracle.com (Per Liden) Date: Thu, 03 Oct 2013 13:44:42 +0200 Subject: RFR: 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 In-Reply-To: <524D52AE.7050605@oracle.com> References: <524D52AE.7050605@oracle.com> Message-ID: <524D58AA.9060704@oracle.com> Looks good! /Per On 2013-10-03 13:19, Stefan Johansson wrote: > Hi, > > Please review this fix for: > https://bugs.openjdk.java.net/browse/JDK-8025661 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8025661/webrev.00/ > > Summary: > The parsing of -Xminf and -Xmaxf has been done with atof() which > doesn't detect errors. If using strtod() instead it's possible verify > whether the whole input was parsed or not. > > Also added a test to verify that we detect ill-formed input after the > change. > > Thanks, > StefanJ From stefan.johansson at oracle.com Thu Oct 3 05:03:54 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 03 Oct 2013 14:03:54 +0200 Subject: RFR: 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 In-Reply-To: <524D58AA.9060704@oracle.com> References: <524D52AE.7050605@oracle.com> <524D58AA.9060704@oracle.com> Message-ID: <524D5D2A.3070302@oracle.com> Thanks Per! On 2013-10-03 13:44, Per Liden wrote: > Looks good! > > /Per > > On 2013-10-03 13:19, Stefan Johansson wrote: >> Hi, >> >> Please review this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8025661 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8025661/webrev.00/ >> >> Summary: >> The parsing of -Xminf and -Xmaxf has been done with atof() which >> doesn't detect errors. If using strtod() instead it's possible verify >> whether the whole input was parsed or not. >> >> Also added a test to verify that we detect ill-formed input after the >> change. >> >> Thanks, >> StefanJ > From stefan.johansson at oracle.com Thu Oct 3 05:07:45 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 03 Oct 2013 14:07:45 +0200 Subject: RFR: 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 In-Reply-To: <524D5857.7020201@oracle.com> References: <524D52AE.7050605@oracle.com> <524D5857.7020201@oracle.com> Message-ID: <524D5E11.6000807@oracle.com> Thanks Bengt, I see your point, updated webrev to use "INVALID" instead of "NAN": http://cr.openjdk.java.net/~sjohanss/8025661/webrev.01/ Cheers, StefanJ On 2013-10-03 13:43, Bengt Rutisson wrote: > > Hi Stefan, > > Looks good! > > One minor nit. In the test you use "NAN" as something that should not > be parsed as a number. Maybe it would be clearer to use something that > is clearly not related to numbers, such as "garbage" or "invalid input". > > Bengt > > On 10/3/13 1:19 PM, Stefan Johansson wrote: >> Hi, >> >> Please review this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8025661 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8025661/webrev.00/ >> >> Summary: >> The parsing of -Xminf and -Xmaxf has been done with atof() which >> doesn't detect errors. If using strtod() instead it's possible verify >> whether the whole input was parsed or not. >> >> Also added a test to verify that we detect ill-formed input after the >> change. >> >> Thanks, >> StefanJ > From alejandro.murillo at oracle.com Thu Oct 3 05:58:25 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 03 Oct 2013 06:58:25 -0600 Subject: Code review request 8025861: Set minor version for hotspot in 7u60 to 60 and build number to b01 In-Reply-To: References: <524CFB92.3000601@oracle.com> Message-ID: <524D69F1.8080605@oracle.com> Thanks Stefan and Staffan for the prompt review Alejandro On 10/3/2013 12:30 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 3 okt 2013, at 07:07, Alejandro E Murillo wrote: > >> Can I get a quick review of this change: >> >> 8025861 : Set minor version for hotspot in 7u60 to 60 and build number to b01 >> >> >> http://cr.openjdk.java.net/~amurillo/7u60/8025861_webrev/ >> >> Thanks >> >> -- >> Alejandro >> -- Alejandro From bengt.rutisson at oracle.com Thu Oct 3 06:26:56 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 03 Oct 2013 15:26:56 +0200 Subject: RFR: 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 In-Reply-To: <524D5E11.6000807@oracle.com> References: <524D52AE.7050605@oracle.com> <524D5857.7020201@oracle.com> <524D5E11.6000807@oracle.com> Message-ID: <524D70A0.50609@oracle.com> On 10/3/13 2:07 PM, Stefan Johansson wrote: > Thanks Bengt, > > I see your point, updated webrev to use "INVALID" instead of "NAN": > http://cr.openjdk.java.net/~sjohanss/8025661/webrev.01/ Thanks for the quick fix. Looks good. Bengt > > Cheers, > StefanJ > > On 2013-10-03 13:43, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> Looks good! >> >> One minor nit. In the test you use "NAN" as something that should not >> be parsed as a number. Maybe it would be clearer to use something >> that is clearly not related to numbers, such as "garbage" or "invalid >> input". >> >> Bengt >> >> On 10/3/13 1:19 PM, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8025661 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8025661/webrev.00/ >>> >>> Summary: >>> The parsing of -Xminf and -Xmaxf has been done with atof() which >>> doesn't detect errors. If using strtod() instead it's possible >>> verify whether the whole input was parsed or not. >>> >>> Also added a test to verify that we detect ill-formed input after >>> the change. >>> >>> Thanks, >>> StefanJ >> > From coleen.phillimore at oracle.com Thu Oct 3 07:31:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Oct 2013 10:31:12 -0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524D3E58.9000307@oracle.com> References: <524C7197.7060603@oracle.com> <524D3E58.9000307@oracle.com> Message-ID: <524D7FB0.5060003@oracle.com> Hi Vladimir, The change looks good but what testing have you done with this? Have you run Kitchensink and the aurora tests? We might start getting a whole bunch of failures now which is good in a way but it would be good to know beforehand that they are coming. And start investigating whether this is benign in certain cases, which is why someone made this a warning in the first place. Thanks, Coleen On 10/03/2013 05:52 AM, Vladimir Ivanov wrote: > Thank you, Roland. > > Best regards, > Vladimir Ivanov > > On 10/3/13 12:11 PM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ >> >> That looks good to me. >> >> Roland. >> From vladimir.x.ivanov at oracle.com Thu Oct 3 07:55:55 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 18:55:55 +0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524D7FB0.5060003@oracle.com> References: <524C7197.7060603@oracle.com> <524D3E58.9000307@oracle.com> <524D7FB0.5060003@oracle.com> Message-ID: <524D857B.5060404@oracle.com> Coleen, I ran full set of VM tests on supported platforms. While investigating 8023461, I ran runThese in different configurations trying to reproduce the failure w/o any success. It shouldn't pollute test results. Looking at test results, such warnings are rare. Started Kitchensink run. Will let you know about the results. Best regards, Vladimir Ivanov On 10/3/13 6:31 PM, Coleen Phillimore wrote: > > Hi Vladimir, > The change looks good but what testing have you done with this? Have you > run Kitchensink and the aurora tests? We might start getting a whole > bunch of failures now which is good in a way but it would be good to > know beforehand that they are coming. And start investigating whether > this is benign in certain cases, which is why someone made this a > warning in the first place. > Thanks, > Coleen > > On 10/03/2013 05:52 AM, Vladimir Ivanov wrote: >> Thank you, Roland. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 12:11 PM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ >>> >>> That looks good to me. >>> >>> Roland. >>> > From coleen.phillimore at oracle.com Thu Oct 3 08:02:04 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Oct 2013 11:02:04 -0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524D857B.5060404@oracle.com> References: <524C7197.7060603@oracle.com> <524D3E58.9000307@oracle.com> <524D7FB0.5060003@oracle.com> <524D857B.5060404@oracle.com> Message-ID: <524D86EC.1050400@oracle.com> Ok, that's good. Check on kitchensink in a bit and if it's ok, ship it! Thanks, Coleen On 10/03/2013 10:55 AM, Vladimir Ivanov wrote: > Coleen, > > I ran full set of VM tests on supported platforms. > > While investigating 8023461, I ran runThese in different > configurations trying to reproduce the failure w/o any success. > > It shouldn't pollute test results. Looking at test results, such > warnings are rare. > > Started Kitchensink run. Will let you know about the results. > > Best regards, > Vladimir Ivanov > > On 10/3/13 6:31 PM, Coleen Phillimore wrote: >> >> Hi Vladimir, >> The change looks good but what testing have you done with this? Have you >> run Kitchensink and the aurora tests? We might start getting a whole >> bunch of failures now which is good in a way but it would be good to >> know beforehand that they are coming. And start investigating whether >> this is benign in certain cases, which is why someone made this a >> warning in the first place. >> Thanks, >> Coleen >> >> On 10/03/2013 05:52 AM, Vladimir Ivanov wrote: >>> Thank you, Roland. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/3/13 12:11 PM, Roland Westrelin wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ >>>> >>>> That looks good to me. >>>> >>>> Roland. >>>> >> From vladimir.x.ivanov at oracle.com Thu Oct 3 08:13:09 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 19:13:09 +0400 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524D86EC.1050400@oracle.com> References: <524C7197.7060603@oracle.com> <524D3E58.9000307@oracle.com> <524D7FB0.5060003@oracle.com> <524D857B.5060404@oracle.com> <524D86EC.1050400@oracle.com> Message-ID: <524D8985.6040509@oracle.com> Thank you, Coleen. Best regards, Vladimir Ivanov On 10/3/13 7:02 PM, Coleen Phillimore wrote: > > Ok, that's good. Check on kitchensink in a bit and if it's ok, ship it! > Thanks, > Coleen > > On 10/03/2013 10:55 AM, Vladimir Ivanov wrote: >> Coleen, >> >> I ran full set of VM tests on supported platforms. >> >> While investigating 8023461, I ran runThese in different >> configurations trying to reproduce the failure w/o any success. >> >> It shouldn't pollute test results. Looking at test results, such >> warnings are rare. >> >> Started Kitchensink run. Will let you know about the results. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 6:31 PM, Coleen Phillimore wrote: >>> >>> Hi Vladimir, >>> The change looks good but what testing have you done with this? Have you >>> run Kitchensink and the aurora tests? We might start getting a whole >>> bunch of failures now which is good in a way but it would be good to >>> know beforehand that they are coming. And start investigating whether >>> this is benign in certain cases, which is why someone made this a >>> warning in the first place. >>> Thanks, >>> Coleen >>> >>> On 10/03/2013 05:52 AM, Vladimir Ivanov wrote: >>>> Thank you, Roland. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/3/13 12:11 PM, Roland Westrelin wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ >>>>> >>>>> That looks good to me. >>>>> >>>>> Roland. >>>>> >>> > From vladimir.kozlov at oracle.com Thu Oct 3 09:19:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 09:19:34 -0700 Subject: RFR (XS): 8025842: Convert warning("Thread holding lock at safepoint that vm can block on", ...) to fatal(...) In-Reply-To: <524C7197.7060603@oracle.com> References: <524C7197.7060603@oracle.com> Message-ID: <524D9916.6050103@oracle.com> Good. Vladimir On 10/2/13 12:18 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8025842/webrev.00/ > 1 line changed: 0 ins; 0 del; 1 mod > > Warnings are mostly ignored during testing - tests rarely looks at VM output. But this check may reveal a serious > problem which is hard to diagnose (possible deadlock between VM thread & suspended Java thread). > > If it is converted to an assert, the crash log will contain enough information to find the place where VM lock is > acquired, since the check is performed on a thread which hold the lock. > > The change doesn't affect product - the check is guarded by #ifdef ASSERT. > > Inspired by JDK-8023461 [1] > > Testing: JPRT, VM testbase. > > Reviewed-by: ? > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8023461 From christian.thalinger at oracle.com Thu Oct 3 10:12:22 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 10:12:22 -0700 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <508C540C-C923-4888-AA49-F3BD80FEDE6C@oracle.com> Vote: yes On Oct 1, 2013, at 11:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From christian.thalinger at oracle.com Thu Oct 3 10:17:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 10:17:51 -0700 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions In-Reply-To: <524B674A.8080201@oracle.com> References: <524A16C0.4080606@oracle.com> <524B674A.8080201@oracle.com> Message-ID: <790C6F6C-2FAC-4280-8989-D324AECFC6A3@oracle.com> On Oct 1, 2013, at 5:22 PM, Mikael Vidstedt wrote: > > Coleen/Christian/Chris/Dmitry - Thanks for the reviews. > > Since this is only relevant on pre-1.4 JDKs I actually really think nobody depends on this. > > I noticed that I needed one small additional change in nativeLookup.cpp - the struct is iterated over in the function just below (lookup_special_native) and the start index was previously initialized to 2 for jdk1.4+, skipping the first two entries in the array. With that change in place everything works as expected. Right, I missed that. Looks good. > > I uploaded a webrev with that change included for the curious: > > http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.01/webrev/ > > Cheers, > Mikael > > On 2013-09-30 18:27, Christian Thalinger wrote: >> 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 >>> > From igor.veresov at oracle.com Thu Oct 3 10:29:06 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 03 Oct 2013 17:29:06 +0000 Subject: hg: hsx/hotspot-main/hotspot: 13 new changesets Message-ID: <20131003172938.AC30962D0C@hg.openjdk.java.net> Changeset: 72b7e96c1922 Author: twisti Date: 2013-09-26 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/72b7e96c1922 8024545: make develop and notproduct flag values available in product builds Reviewed-by: dholmes, kvn ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryService.cpp Changeset: c9ccd7b85f20 Author: rbackman Date: 2013-09-27 08:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9ccd7b85f20 8024924: Intrinsify java.lang.Math.addExact Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + src/share/vm/opto/mathexactnode.cpp + src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/CondTest.java + test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/LoadTest.java + test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/NonConstantTest.java + test/compiler/intrinsics/mathexact/Verify.java Changeset: 510fbd28919c Author: anoll Date: 2013-09-27 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/510fbd28919c 8020151: PSR:PERF Large performance regressions when code cache is filled Summary: Code cache sweeping based on method hotness; removed speculatively disconnect Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/trace/trace.xml Changeset: a07c25e4f67e Author: adlertz Date: 2013-09-27 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a07c25e4f67e Merge ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: 1c3486050433 Author: adlertz Date: 2013-09-27 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1c3486050433 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e8e077292da3 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8e077292da3 8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc Reviewed-by: twisti ! 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 Changeset: 303826f477c6 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/303826f477c6 8023452: TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: f2512d89ad0c Author: twisti Date: 2013-09-28 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f2512d89ad0c 8025613: clang: remove -Wno-unused-value Reviewed-by: iveresov ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp Changeset: 29bdcf12457c Author: shade Date: 2013-09-27 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/29bdcf12457c 8014447: Object.hashCode intrinsic breaks inline caches Summary: Try to inline as normal method first, then fall back to intrinsic. Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp Changeset: d8d059e90ec1 Author: twisti Date: 2013-09-30 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8d059e90ec1 8025599: Missing store barrier with OptimizeStringConcat Reviewed-by: kvn, twisti Contributed-by: Axel Siebenborn ! src/share/vm/opto/graphKit.cpp Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java + test/compiler/jsr292/methodHandleExceptions/C.java + test/compiler/jsr292/methodHandleExceptions/I.java + test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp From john.coomes at oracle.com Thu Oct 3 10:32:52 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 17:32:52 +0000 Subject: hg: hsx/hotspot-main: 5 new changesets Message-ID: <20131003173253.40FF562D0D@hg.openjdk.java.net> Changeset: 5ec3c4948863 Author: ksrini Date: 2013-09-27 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5ec3c4948863 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, erikj ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk Changeset: 72c2495c86c9 Author: katleman Date: 2013-10-01 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/72c2495c86c9 Merge Changeset: 0f704e36bc5d Author: ihse Date: 2013-10-01 10:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0f704e36bc5d 8006661: Use LC_ALL=C instead of LANG=C compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 4faa09c7fe55 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4faa09c7fe55 Merge Changeset: 669e3e3d4459 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/669e3e3d4459 Added tag jdk8-b110 for changeset 4faa09c7fe55 ! .hgtags From john.coomes at oracle.com Thu Oct 3 10:33:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 17:33:01 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b110 for changeset 3d2b7ce93c5c Message-ID: <20131003173306.3D44E62D0E@hg.openjdk.java.net> Changeset: 85c1c94e7235 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/85c1c94e7235 Added tag jdk8-b110 for changeset 3d2b7ce93c5c ! .hgtags From john.coomes at oracle.com Thu Oct 3 10:34:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 17:34:30 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b110 for changeset cc682329886b Message-ID: <20131003173439.0E12562D11@hg.openjdk.java.net> Changeset: 32edc7a2c866 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/32edc7a2c866 Added tag jdk8-b110 for changeset cc682329886b ! .hgtags From john.coomes at oracle.com Thu Oct 3 10:33:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 17:33:35 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b110 for changeset 4c84c5b447b0 Message-ID: <20131003173406.60A3362D0F@hg.openjdk.java.net> Changeset: 17ee0d3e97fd Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/17ee0d3e97fd Added tag jdk8-b110 for changeset 4c84c5b447b0 ! .hgtags From john.coomes at oracle.com Thu Oct 3 10:38:52 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 17:38:52 +0000 Subject: hg: hsx/hotspot-main/jdk: 115 new changesets Message-ID: <20131003181324.6E78A62D14@hg.openjdk.java.net> Changeset: 529cd4de1823 Author: prr Date: 2013-09-26 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/529cd4de1823 7092764: java.awt.font.TransformAttribute.equals(null) throws NPE Reviewed-by: jgodinez, jchen ! src/share/classes/java/awt/font/TransformAttribute.java + test/java/awt/font/TransformAttribute/TransformEqualityTest.java Changeset: 1bcd48cfb7be Author: ceisserer Date: 2013-09-26 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1bcd48cfb7be 8024895: xrender MaskImage cache isn't accounting for change in alpha Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java + test/java/awt/image/DrawImage/EABlitTest.java Changeset: dae020405903 Author: lana Date: 2013-09-26 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dae020405903 Merge Changeset: 0151f12bd392 Author: malenkov Date: 2013-08-22 17:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0151f12bd392 8023536: Some regression tests have a wrong header Reviewed-by: alexsch ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/javax/swing/JTree/8013571/Test8013571.java Changeset: b71f112dab2a Author: malenkov Date: 2013-08-22 21:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b71f112dab2a 7057769: JScrollBar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/javax/swing/JScrollBar.java Changeset: f983fd18dd81 Author: malenkov Date: 2013-08-23 19:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f983fd18dd81 7080613: java.beans.DefaultPersistenceDelegate.instantiate(..) doesn't throw NPE Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/PersistenceDelegate.java Changeset: 22ef5187a3e6 Author: dmarkov Date: 2013-08-26 17:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/22ef5187a3e6 8023474: First mousepress doesn't start editing in JTree Reviewed-by: alexp, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java Changeset: abd068530590 Author: malenkov Date: 2013-08-27 12:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abd068530590 7195179: ClassCastException for null values in JComboBox Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/7195179/Test7195179.java Changeset: 92adff44c841 Author: malenkov Date: 2013-08-27 13:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92adff44c841 8021379: JFileChooser Create New Folder button enabled in write proteced directory Reviewed-by: alexsch ! src/share/classes/sun/swing/FilePane.java Changeset: 4bfcf9c5ced3 Author: malenkov Date: 2013-08-27 13:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bfcf9c5ced3 8022398: javax/swing/JFileChooser/8013442/Test8013442.java fails Reviewed-by: alexsch ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java + src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: e11ed7187b0c Author: lana Date: 2013-08-27 21:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e11ed7187b0c Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 43de418f1345 Author: ptbrunet Date: 2013-08-28 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43de418f1345 8011955: Lunar screen reader crashes intermittently in WindowsAccessBridge-32.DLL 6995891: JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue 8014738: Combobox menu items are not announced with JAWS 8011938: Java Ferret example corrupts JCombobox of the running application 8012011: JAB 2.0.2 incompletely shows kbd accelerator in menus 8022966: Java Access Bridge no longer usable with screen magnifiers Reviewed-by: raginip, tbell, erikj, art ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcMisc.gmk Changeset: 35644adc3269 Author: malenkov Date: 2013-08-28 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/35644adc3269 6968363: ClassCastException while entering HINDI characters with CustomDocument Reviewed-by: alexsch ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/AbstractDocument/6968363/Test6968363.java Changeset: 6432f8749e1d Author: pchelko Date: 2013-08-30 11:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6432f8749e1d 8023966: JViewPort.BLIT_SCROLL_MODE does not work in JLightweightFrame Reviewed-by: anthony, ant ! src/share/classes/javax/swing/JViewport.java Changeset: 7151f08eeadf Author: alexsch Date: 2013-08-30 13:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7151f08eeadf 8022401: [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java Changeset: f2f614e31522 Author: malenkov Date: 2013-09-02 14:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2f614e31522 7156658: JTextComponent.setFocusAccelerator() spec does not state that focus accelerator is L&F dependent Reviewed-by: alexsch ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 6ffa2680e139 Author: art Date: 2013-09-02 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ffa2680e139 8022184: Fix static , Raw warnings in classes belonging to java.awt Reviewed-by: art, anthony Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/WaitDispatchSupport.java Changeset: b5ed8686cc01 Author: malenkov Date: 2013-09-03 11:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b5ed8686cc01 6943780: JTabbedPane throws ArrayIndexOutOfBoundsException sometimes Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/plaf/basic/BasicTabbedPaneUI/Test6943780.java Changeset: 80a8c4ff3b51 Author: alexsch Date: 2013-09-03 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/80a8c4ff3b51 8007156: [macosx] Wrong events in processKeyBinding of JTable Submit Date Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java Changeset: 2ad01ecbaf90 Author: malenkov Date: 2013-09-03 21:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ad01ecbaf90 7172865: PropertyDescriptor fails to work with setter method name if setter is non-void Reviewed-by: art, alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java + src/share/classes/java/beans/MethodRef.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7172865.java Changeset: ba711056009f Author: pchelko Date: 2013-09-04 14:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba711056009f 8021943: FileDialog getFile returns corrupted string after previous setFile Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: ba041df8a554 Author: mcherkas Date: 2013-09-04 18:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba041df8a554 8023565: JPG causes javax.imageio.IIOException: ICC APP2 encoutered without prior JFIF Reviewed-by: bae, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java Changeset: e4ba3d9ea041 Author: mcherkas Date: 2013-09-05 15:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e4ba3d9ea041 8023392: Swing text components printed with spaces between chars Reviewed-by: alexsch, alexp Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java + test/java/awt/print/bug8023392/bug8023392.html + test/java/awt/print/bug8023392/bug8023392.java Changeset: d267c066b006 Author: lana Date: 2013-09-06 15:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d267c066b006 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: fbb6f976d780 Author: alexsch Date: 2013-09-09 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fbb6f976d780 8024413: Add tests for issues JDK-8002077 and JDK-7199708 Reviewed-by: malenkov, leonidr + test/javax/swing/JFileChooser/7199708/bug7199708.java + test/javax/swing/JFileChooser/8002077/bug8002077.java Changeset: 3ea08767fc0d Author: alexsch Date: 2013-09-09 18:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3ea08767fc0d 8020060: MoleculeViewerTest demo doesn't work due to SecurityPermissions Reviewed-by: malenkov, erikj ! makefiles/CompileDemos.gmk ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/MoleculeViewer/example1.html ! src/share/demo/applets/MoleculeViewer/example2.html ! src/share/demo/applets/MoleculeViewer/example3.html ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/applets/WireFrame/example1.html ! src/share/demo/applets/WireFrame/example2.html ! src/share/demo/applets/WireFrame/example3.html ! src/share/demo/applets/WireFrame/example4.html Changeset: fc5d16fec25f Author: serb Date: 2013-09-09 21:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fc5d16fec25f 8023042: Inaccuracy in documentation in a sound area Reviewed-by: prr ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java Changeset: 9d0d961fb1cd Author: pchelko Date: 2013-09-10 11:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d0d961fb1cd 8024381: The test for 8020210 does not have @bug tag Reviewed-by: anthony, serb ! test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: 8b6dace81d6c Author: alexsch Date: 2013-09-10 14:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b6dace81d6c 8021253: JFileChooser does not react on pressing enter since java 7 Reviewed-by: malenkov ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/8021253/bug8021253.java Changeset: 1daffcf035c4 Author: malenkov Date: 2013-09-10 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1daffcf035c4 7057770: (spec)Scrollbar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/java/awt/Scrollbar.java Changeset: eedb2b6d93ec Author: malenkov Date: 2013-09-10 17:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eedb2b6d93ec 8024407: [macosx] javax/swing/JScrollBar/7163696/Test7163696.java failed intermittently on macos Reviewed-by: alexsch ! test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: 0cc00c11e17e Author: leonidr Date: 2013-09-10 20:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0cc00c11e17e 8003901: [macosx] Need test for JDK-8002114 Reviewed-by: anthony, serb ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 04fbd34fda7b Author: bagiras Date: 2013-09-12 14:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04fbd34fda7b 8003965: Toolkit.beep() documentation is ambiguous Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: def1fa9854f7 Author: bagiras Date: 2013-09-12 15:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/def1fa9854f7 7064312: Cleanup: avoid using unsafe string function Reviewed-by: serb, pchelko ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_ole.cpp Changeset: 6321e4429a38 Author: serb Date: 2013-09-12 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6321e4429a38 7124537: [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 3213c388740a Author: dmarkov Date: 2013-09-12 18:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3213c388740a 8024395: Improve fix for line break calculations Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/View.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: ef2f0c15b332 Author: pchelko Date: 2013-09-13 11:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ef2f0c15b332 8024170: [SwingNode] Implement cursor change Reviewed-by: anthony, ant ! src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java Changeset: 12788c245d67 Author: pchelko Date: 2013-09-13 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12788c245d67 8015453: java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java failed on windows with jdk8 since b86 Reviewed-by: art, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: df107b1f2f2e Author: pchelko Date: 2013-09-13 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/df107b1f2f2e 8015371: The HTML text without tags does not appear inside the WordPad application, and we try to click the button, but the case exits. Reviewed-by: anthony, serb ! src/windows/classes/sun/awt/windows/WDataTransferer.java Changeset: 40fdf56c09a9 Author: pchelko Date: 2013-09-13 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40fdf56c09a9 8015455: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java hangs on windows Reviewed-by: serb, anthony ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/javax/swing/TransferHandler.java Changeset: 915d13946f18 Author: mcherkas Date: 2013-09-13 17:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/915d13946f18 8015601: [macosx] Test javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java fails on MacOS X Reviewed-by: alexp, alexsch ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: ad52e924c55a Author: kshefov Date: 2013-09-13 17:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad52e924c55a 8006087: [TEST_BUG] The BACKSPACE key doesn't work and after pressing 'cancel' and 'DONE' button, the case pass automatically. Reviewed-by: alexsch, serb ! test/javax/swing/JFileChooser/4150029/bug4150029.html ! test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: c8a85165b725 Author: kshefov Date: 2013-09-13 17:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8a85165b725 8015597: [TEST_BUG] [macosx] Test closed/javax/swing/JMenuBar/4750590/bug4750590.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/JMenuBar/4750590/bug4750590.java Changeset: 17cc8f13e4e7 Author: pchelko Date: 2013-09-13 18:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17cc8f13e4e7 8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS Reviewed-by: anthony, serb ! make/sun/lwawt/FILES_export_macosx.gmk - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: a46d22ee4d4b Author: alexsch Date: 2013-09-16 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a46d22ee4d4b 8008728: [macosx] Swing. JDialog. Modal dialog goes to background Reviewed-by: serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java Changeset: 8f5b4e7623cf Author: ant Date: 2013-09-16 18:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8f5b4e7623cf 8022512: JLightweightFrame: the content pane should be transparent Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 49c7d299a504 Author: kshefov Date: 2013-09-16 19:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/49c7d299a504 7020060: [TEST_BUG] java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed Reviewed-by: anthony, serb ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: 98080e9367be Author: kshefov Date: 2013-09-16 19:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98080e9367be 8015588: [TEST_BUG] [macosx] Test java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java fails on MacOSX Reviewed-by: anthony, serb ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 04612a52e7bd Author: pchelko Date: 2013-09-16 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04612a52e7bd 8024779: [macosx] SwingNode crashes on exit Reviewed-by: anthony, ant ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 4e88bf592830 Author: pchelko Date: 2013-09-16 19:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4e88bf592830 8024485: For 5-1 step: if input something into the 'File:' and 'Dir:', the dir output isn't empty in the output window after showing and canceling the file dialog Reviewed-by: serb, anthony ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 8530456e0091 Author: omajid Date: 2013-09-16 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8530456e0091 8024863: X11: Support GNOME Shell as mutter Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWM.java Changeset: 4899f6734a14 Author: ant Date: 2013-09-18 12:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4899f6734a14 8024839: [Unified Swing/Fx threading] don't schedule an event dispatching from the event dispatch thread Reviewed-by: anthony, pchelko ! src/share/classes/java/awt/EventQueue.java Changeset: cc7a15f4c735 Author: mcherkas Date: 2013-09-18 15:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc7a15f4c735 8016746: Test javax/swing/JTable/7068740/bug7068740.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JTable/7068740/bug7068740.java Changeset: 2c240454c192 Author: leonidr Date: 2013-09-18 18:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c240454c192 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java Changeset: 20b1135647fa Author: lana Date: 2013-09-18 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/20b1135647fa Merge ! src/share/classes/java/awt/Toolkit.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/windows/native/sun/windows/awt_PrintControl.cpp - 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: e292d504ad68 Author: leonidr Date: 2013-09-19 22:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e292d504ad68 7144065: [macosx] Orphaned Choice popup window Reviewed-by: anthony, serb Contributed-by: alexander.potochkin at oracle.com ! src/macosx/classes/sun/lwawt/LWChoicePeer.java Changeset: 602e5d0141d3 Author: leonidr Date: 2013-09-19 23:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/602e5d0141d3 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, serb ! makefiles/GensrcProperties.gmk + src/macosx/classes/sun/awt/resources/awtosx.properties ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/AWTAccessor.java + test/java/awt/Toolkit/ToolkitPropertyTest/bug7129133.java Changeset: c04e55e17066 Author: kshefov Date: 2013-09-20 17:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c04e55e17066 7124314: [TEST_BUG] [macosx] Aqua LAF: JTree doesn't select element by keyboards left and right keys Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JTree/4927934/bug4927934.java Changeset: 6c1f9468f3de Author: kshefov Date: 2013-09-20 17:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c1f9468f3de 8017180: [macosx] [TEST_BUG] alt-key doesn't work on macos for menu Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/javax/swing/JMenuItem/4171437/bug4171437.java + test/javax/swing/JPopupMenu/4458079/bug4458079.java Changeset: f139aef966fd Author: kshefov Date: 2013-09-20 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f139aef966fd 7124232: [TEST_BUG] [macosx] JSplitPane has wrong divider location Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: abebe03818f6 Author: malenkov Date: 2013-09-20 18:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abebe03818f6 7024235: Nimbus L&F: wrong "packing" of a frame containing tabbed pane Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7024235/Test7024235.java Changeset: 2ac59698de38 Author: kshefov Date: 2013-09-23 16:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ac59698de38 8015600: [TEST_BUG] [macosx] Test closed/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java Changeset: eac52fe3990c Author: serb Date: 2013-09-23 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eac52fe3990c 8005255: [macosx] Cleanup warnings in sun.lwawt Reviewed-by: alexsch, anthony ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java - src/macosx/classes/sun/lwawt/SelectionClearListener.java Changeset: 2684fd4e9f3b Author: serb Date: 2013-09-23 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2684fd4e9f3b 7172833: For default java.awt.Toolkit impl methods java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: alexsch, anthony ! src/share/classes/java/awt/Toolkit.java + test/java/awt/Toolkit/DynamicLayout/bug7172833.java Changeset: d73d3a29065c Author: serb Date: 2013-09-23 21:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d73d3a29065c 8019282: keyRelesed is reached even though key was NOT released Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! make/sun/xawt/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 8c0b943a0090 Author: yan Date: 2013-09-24 12:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8c0b943a0090 8025114: Eliminate doclint errors in java.awt.dnd package javadoc Reviewed-by: serb, alexsch ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/share/classes/java/awt/dnd/DropTargetDropEvent.java Changeset: 1303823e89da Author: yan Date: 2013-09-24 16:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1303823e89da 8025230: [cleanup] some more javadoc formatting fixes for swing Reviewed-by: alexsch ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java Changeset: d580e0bc85d9 Author: yan Date: 2013-09-24 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d580e0bc85d9 8025117: [cleanup] Eliminate doclint errors in javax/swing/text classes Reviewed-by: alexsch ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/Caret.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/EditorKit.java ! src/share/classes/javax/swing/text/FieldView.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/NavigationFilter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/PasswordView.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/PlainView.java ! src/share/classes/javax/swing/text/Position.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledDocument.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabExpander.java ! src/share/classes/javax/swing/text/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 58178aec7e81 Author: kshefov Date: 2013-09-24 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/58178aec7e81 7124320: [TEST_BUG] [macosx] JComboBox doesn't change selection on mouse over Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JComboBox/6236162/bug6236162.java Changeset: f500844c2253 Author: kshefov Date: 2013-09-24 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f500844c2253 7133154: [TEST_BUG] [macosx] closed/javax/swing/JInternalFrame/4251301/bug4251301.java fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4251301/bug4251301.java Changeset: 967557d5b90a Author: kshefov Date: 2013-09-24 18:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/967557d5b90a 7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4193219/IconCoord.java Changeset: 3982dd1210ba Author: kshefov Date: 2013-09-24 18:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3982dd1210ba 8015599: [TEST_BUG] [macosx] Test closed/javax/swing/Popup/TaskbarPositionTest.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/Popup/TaskbarPositionTest.java Changeset: 2ed1584d62c5 Author: leonidr Date: 2013-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ed1584d62c5 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily Reviewed-by: anthony, serb ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java Changeset: a284da808700 Author: malenkov Date: 2013-09-25 14:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a284da808700 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: art, sfriberg ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 10e66428ddb0 Author: alexsch Date: 2013-09-25 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/10e66428ddb0 8007155: [macosx] Disabled panel takes mouse input in JLayeredPane Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/windows/classes/sun/awt/windows/WGlobalCursorManager.java ! src/windows/native/sun/windows/awt_Container.cpp ! src/windows/native/sun/windows/awt_Container.h ! src/windows/native/sun/windows/awt_Cursor.cpp + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.html + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.java Changeset: 7cad8ef127a9 Author: pchelko Date: 2013-09-25 16:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7cad8ef127a9 8024987: Copy/paste regression since JDK8 b86 Reviewed-by: serb, anthony ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: cff4f079fa3f Author: kshefov Date: 2013-09-25 16:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cff4f079fa3f 8004032: [TEST_BUG] [macosx] There is no effect when double clicking on the Icon, after right clicking on the Icon and the Icon disappear Reviewed-by: anthony, serb + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java Changeset: 681ac9f9c452 Author: alexsch Date: 2013-09-25 17:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/681ac9f9c452 8025070: [javadoc] fix some javadoc errors in javax/swing/plaf/synth Reviewed-by: serb, alexsch Contributed-by: Alexander Stepanov ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPainter.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 2f8803ebd98c Author: yan Date: 2013-09-25 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f8803ebd98c 8025085: [javadoc] some errors in javax/swing Reviewed-by: alexsch Contributed-by: Dmitry Zinkevich ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/InlineView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: c40ed21f2939 Author: alexsch Date: 2013-09-25 17:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c40ed21f2939 7083457: Incomplete specification for javax/swing/text/DefaultCaret.html#setVisible(boolean) Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/7083457/bug7083457.java Changeset: 09fb25645717 Author: ptbrunet Date: 2013-09-26 10:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/09fb25645717 8025160: Recent Java Accessibility Bridge push has make failures Reviewed-by: tbell, erikj ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 0270e9b0891b Author: yan Date: 2013-09-26 16:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0270e9b0891b 8025218: [javadoc] some errors in java/awt classes Reviewed-by: yan Contributed-by: Dmitry Zinkevich ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/event/MouseMotionListener.java Changeset: 3b22833f2695 Author: lana Date: 2013-09-26 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b22833f2695 Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java Changeset: 8708569b5524 Author: sjiang Date: 2013-09-18 08:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8708569b5524 8023954: MBean*Info.equals: throw NPE Reviewed-by: dfuchs, dholmes ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java + test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java Changeset: ee8b292ee568 Author: weijun Date: 2013-09-18 18:22 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ee8b292ee568 8012615: Realm.getRealmsList returns realms list in wrong Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! test/sun/security/krb5/ParseCAPaths.java ! test/sun/security/krb5/krb5-capaths.conf Changeset: e92635d6834c Author: alanb Date: 2013-09-18 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e92635d6834c 8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx) Reviewed-by: alanb, coffeys Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java Changeset: 07d73060e0da Author: weijun Date: 2013-09-18 21:37 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/07d73060e0da 8011402: Move blacklisting certificate logic from hard code to data Reviewed-by: erikj, mullan ! make/java/security/Makefile ! makefiles/CopyFiles.gmk ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/sun/security/util/UntrustedCertificates.java ! src/share/classes/sun/security/x509/X509CertImpl.java + src/share/lib/security/BlacklistedCertsConverter.java + src/share/lib/security/blacklisted.certs + src/share/lib/security/blacklisted.certs.pem + test/lib/security/CheckBlacklistedCerts.java Changeset: b3a506a30fda Author: ewang Date: 2013-09-18 15:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3a506a30fda 8015762: TEST_BUG: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failing intermittently [win] Reviewed-by: chegar, alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java Changeset: 22e9f0067b5a Author: kizune Date: 2013-09-19 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/22e9f0067b5a 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/sun/launcher/LauncherHelper.java + test/tools/launcher/8017248/ClassA??.java + test/tools/launcher/8017248/test.sh Changeset: 7557062d2dd2 Author: plevart Date: 2013-09-19 16:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7557062d2dd2 8011940: java.lang.Class.getAnnotations() always enters synchronized method Reviewed-by: jfranck, chegar, psandoz, shade ! src/share/classes/java/lang/Class.java + test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java Changeset: 278873b2b3f8 Author: sherman Date: 2013-09-19 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/278873b2b3f8 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists Summary: updated the test case Reviewed-by: alanb ! test/tools/jar/ChangeDir.java Changeset: f36714707c38 Author: psandoz Date: 2013-09-18 10:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f36714707c38 8025002: "".codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException Reviewed-by: henryjen, alanb ! src/share/classes/java/lang/CharSequence.java ! test/java/lang/CharSequence/DefaultTest.java Changeset: 0ef7ddef9de0 Author: psandoz Date: 2013-09-19 20:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ef7ddef9de0 8024405: Spliterators.spliterator should support CONCURRENT characteristic Reviewed-by: martin ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/Spliterators.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 58fd427b454d Author: sla Date: 2013-09-20 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/58fd427b454d 8024985: com/sun/jdi/StepTest.java failed since jdk8b107 Reviewed-by: dcubed ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/JDIScaffold.java ! test/com/sun/jdi/PopAndStepTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/TestScaffold.java Changeset: 6a1c70e191d4 Author: sla Date: 2013-09-20 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a1c70e191d4 8024416: TESTBUG: com/sun/jdi/MethodEntryExitEvents.java: method entry count mismatch Reviewed-by: dcubed ! test/com/sun/jdi/MethodEntryExitEvents.java Changeset: afe857b13b62 Author: kizune Date: 2013-09-20 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/afe857b13b62 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales Reviewed-by: naoto, ksrini - test/tools/launcher/8017248/ClassA??.java - test/tools/launcher/8017248/test.sh + test/tools/launcher/DiacriticTest.java Changeset: 94cc251d0c45 Author: sla Date: 2013-09-20 16:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/94cc251d0c45 7200277: [parfait] potential buffer overflow in npt/utf.c Reviewed-by: dsamersoff, dcubed ! src/share/npt/utf.c Changeset: 7913855ff66c Author: psandoz Date: 2013-09-20 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7913855ff66c 8024253: ThreadLocal random can use SecureRandom for the initial seed Reviewed-by: psandoz, chegar, alanb Contributed-by: Doug Lea
, Peter Levart , Guy Steele ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java Changeset: 2552cd270350 Author: bpb Date: 2013-09-20 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2552cd270350 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent Summary: Explicitly check for null remappingFunction parameter. Reviewed-by: mduigou, forax, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: c30dc8e7744e Author: psandoz Date: 2013-09-20 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c30dc8e7744e 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/PatternStreamTest.java - test/java/util/regex/PatternTest.java Changeset: 56d247821694 Author: alanb Date: 2013-09-23 04:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/56d247821694 8023130: (process) ProcessBuilder#inheritIO does not work on Windows Reviewed-by: alanb, martin Contributed-by: ivan.gerasimov at oracle.com ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh Changeset: a3b17b91127d Author: lana Date: 2013-09-20 19:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a3b17b91127d Merge Changeset: f1b251affc6a Author: lana Date: 2013-09-22 20:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1b251affc6a Merge Changeset: b606775fd1a3 Author: stefank Date: 2013-08-29 11:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b606775fd1a3 8014659: NPG: performance counters for compressed klass space Reviewed-by: jmasa, sla Contributed-by: erik.helin at oracle.com ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 76619d71a7c5 Author: dfuchs Date: 2013-09-25 09:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/76619d71a7c5 8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout Summary: Arbitrary timeouts in the tests @run lines where too agressive for some configurations. The tests will now run with default timeout. Reviewed-by: alanb, mchung ! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java Changeset: 2b928330970a Author: mfang Date: 2013-09-24 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b928330970a 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties + src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java + src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/keytool/Resources_es.java ! src/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/share/classes/sun/security/tools/keytool/Resources_it.java ! src/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 9765801f209f Author: mfang Date: 2013-09-24 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9765801f209f Merge - test/java/util/regex/PatternTest.java Changeset: d16a53d1762f Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d16a53d1762f Merge Changeset: 8f27030686a6 Author: bchristi Date: 2013-09-26 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8f27030686a6 8025173: HashMap.put() replacing an existing key can trigger a resize() Summary: Ensure that HashMap is not resized if we're just replacing a value Reviewed-by: alanb, martin ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/ReplaceExisting.java Changeset: 8edd604bf960 Author: lana Date: 2013-09-26 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8edd604bf960 Merge - test/java/util/regex/PatternTest.java Changeset: 9684ed81cd21 Author: ksrini Date: 2013-09-27 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9684ed81cd21 8020552: [launcher] changes to support removal of Solaris 32-bit distribution 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, dholmes, darcy, alanb, erikj, sla, martin ! makefiles/Images.gmk ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/solaris/bin/java_md_solinux.c ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RunToExit.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/DemoRun.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile + test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/tools/jhat/HatRun.java ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/ChangeDataModel.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/FXLauncherTest.java ! test/tools/launcher/RunpathTest.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java Changeset: 2c7c7b813eb3 Author: katleman Date: 2013-10-01 12:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c7c7b813eb3 Merge - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so Changeset: dd43ccb3bac9 Author: ihse Date: 2013-10-01 11:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd43ccb3bac9 8019219: Fix typo in jdk/makefiles "default" targets Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 54e099776f08 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54e099776f08 Merge Changeset: 9f57d2774603 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f57d2774603 Added tag jdk8-b110 for changeset 54e099776f08 ! .hgtags From john.coomes at oracle.com Thu Oct 3 11:18:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:18:06 +0000 Subject: hg: hsx/hotspot-main/langtools: 35 new changesets Message-ID: <20131003182010.66FDB62D15@hg.openjdk.java.net> Changeset: fdfbc5f0c4ed Author: jjg Date: 2013-09-17 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fdfbc5f0c4ed 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java + test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java + test/tools/javac/doclint/implicitSource/Other.java Changeset: ac6ec071c2b2 Author: alundblad Date: 2013-09-18 14:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ac6ec071c2b2 8024127: javac, Code_attribute.exception_table_langth should be Code_attribute.exception_table_length Summary: exception_table_langth renamed to exception_table_length Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! test/tools/javac/T7093325.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/multicatch/Pos05.java Changeset: a2a5ad0853ed Author: bpatel Date: 2013-09-18 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a2a5ad0853ed 8015249: javadoc fails to document static final fields in annotation types Reviewed-by: jjg + src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeFieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java + test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationTypeField.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java Changeset: 8df12c315ea3 Author: bpatel Date: 2013-09-18 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8df12c315ea3 8024096: some javadoc tests may contain false positive results Reviewed-by: jjg ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java ! test/com/sun/javadoc/testEncoding/EncodeTest.java ! test/com/sun/javadoc/testEncoding/TestEncoding.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 36e342dd57e2 Author: kizune Date: 2013-09-19 17:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/36e342dd57e2 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java Changeset: 8d1c48de706d Author: jlahoda Date: 2013-09-19 17:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8d1c48de706d 8022567: Javac Should Generate Warnings For Raw Array Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 0cfd5baa7154 Author: ohrstrom Date: 2013-09-19 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0cfd5baa7154 8024609: sjavac assertion fails during call to BuildState.collectArtifacts Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java Changeset: 2375ce96e80d Author: vromero Date: 2013-09-19 20:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2375ce96e80d 8024437: Inferring the exception thrown: sometimes fails to compile Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java Changeset: 9a75bdb249a2 Author: jjg Date: 2013-09-19 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9a75bdb249a2 8025110: TreeCopier does not correctly copy LabeledStatementTree Reviewed-by: jjg Contributed-by: Werner Dietl ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java Changeset: 41599b57d262 Author: jlahoda Date: 2013-09-20 16:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/41599b57d262 8023835: TreeMaker.QualIdent() too leafy Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/tree/MakeQualIdent.java + test/tools/javac/tree/ScopeTest.java Changeset: 571f8ebc2d51 Author: vromero Date: 2013-09-22 12:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/571f8ebc2d51 8024696: Missing null check in bound method reference capture Reviewed-by: jjg, briangoetz ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/lambda/8023558/T8023558a.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceNullCheckTest.java Changeset: 86dd72166267 Author: lana Date: 2013-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/86dd72166267 Merge Changeset: 20b72bae83d7 Author: lana Date: 2013-09-22 20:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/20b72bae83d7 Merge Changeset: 1fe358ea75ff Author: alundblad Date: 2013-09-23 10:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1fe358ea75ff 8024988: javac, LVT test harness should generate tests .class files in the scratch folder Summary: Set the CLASS_OUTPUT location to the scratch directory. Changed the argument to checkClassFile accordingly. Reviewed-by: jjg, vromero ! test/tools/javac/flow/LVTHarness.java Changeset: 5f915a0c9615 Author: alundblad Date: 2013-09-23 10:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5f915a0c9615 6386236: Please rename com.sun.tools.javac.util.ListBuffer.lb() Summary: Static factory method ListBuffer.lb removed. Replaced by constructor calls. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.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/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.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/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.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/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 809a50f24d6f Author: kizune Date: 2013-09-23 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/809a50f24d6f 7154966: CRs found to be in Fixed state with no test and no noreg- keyword. Reviewed-by: ksrini + test/tools/javac/T7090499.java + test/tools/javac/T7090499.out + test/tools/javac/T7120463.java + test/tools/javac/T7120463.out + test/tools/javac/T7126754.java Changeset: 64e79d38bd07 Author: kizune Date: 2013-09-23 18:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/64e79d38bd07 4881267: improve diagnostic for "instanceof T" for type parameter T Reviewed-by: vromero, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T4881267.java + test/tools/javac/T4881267.out Changeset: 09301757bb32 Author: emc Date: 2013-09-23 15:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/09301757bb32 6499673: Assertion check for TypeVariable.getUpperBound() fails. Summary: Fix TypeVariable.getUpperBound to return results as specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/processing/model/type/BoundsTest.java + test/tools/javac/processing/model/type/IntersectionPropertiesTest.java Changeset: 96dcb66e6b0a Author: jjg Date: 2013-09-24 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/96dcb66e6b0a 8025050: Doclint doesn't recognize tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/InlineTagsTest.java Changeset: 503338f16d2b Author: jjg Date: 2013-09-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/503338f16d2b 8025246: [doclint] doclint is showing error on anchor already defined when it's not Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/anchorTests/p/Test.java + test/tools/doclint/anchorTests/p/Test.javac.out + test/tools/doclint/anchorTests/p/Test.out + test/tools/doclint/anchorTests/p/package-info.java + test/tools/doclint/anchorTests/p/package-info.javac.out + test/tools/doclint/anchorTests/p/package-info.out Changeset: 6a05a713450d Author: jjg Date: 2013-09-24 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6a05a713450d 8025272: doclint needs to check for valid usage of @value tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/ValueTest.java + test/tools/doclint/ValueTest.out Changeset: 3ae62331a56f Author: jjg Date: 2013-09-24 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3ae62331a56f 8002154: [doclint] doclint should check for issues which are errors in javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out Changeset: 184c0d6698c3 Author: bpatel Date: 2013-09-24 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/184c0d6698c3 8016328: Regression : Javadoc i18n regression caused by fix for 8012375 Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: 5043e7056be8 Author: jjg Date: 2013-09-25 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5043e7056be8 8025407: TypeAnnotations does not use Context Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: 1332a99572c5 Author: mfang Date: 2013-09-24 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1332a99572c5 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties ! src/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties Changeset: daa3bfb82e58 Author: mfang Date: 2013-09-24 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/daa3bfb82e58 Merge Changeset: 6b702ace3e45 Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6b702ace3e45 Merge Changeset: 68292726000e Author: mfang Date: 2013-09-25 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/68292726000e Merge Changeset: 3d61984b077c Author: jjg Date: 2013-09-25 14:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3d61984b077c 8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java Reviewed-by: bpatel ! test/tools/doclint/tidy/util/Main.java ! test/tools/doclint/tidy/util/tidy.sh Changeset: 9e884d3ddb0b Author: bpatel Date: 2013-09-25 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9e884d3ddb0b 8004825: javadoc crash DocletAbortException Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testValueTag/pkg1/Class1.java Changeset: 9235ae08a449 Author: jlahoda Date: 2013-09-26 20:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9235ae08a449 8025491: Javac regression test tools/javac/T8003967/DetectMutableStaticFields.java failing Summary: Making HtmlTree.NONENCODING_CHARS final Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java Changeset: 13eba2e322e6 Author: vromero Date: 2013-09-26 19:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/13eba2e322e6 8025139: javac patch for using bootstrap compiler for debugging is not working properly Reviewed-by: jjg ! make/netbeans/langtools/build.xml ! make/tools/anttasks/SelectToolTask.java Changeset: 17653c4c22ec Author: sogoel Date: 2013-09-26 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/17653c4c22ec 8011738: Write test to check for bootstrap attributes for lambda expressions in class file Reviewed-by: mcimadamore + test/tools/javac/lambda/ByteCodeTest.java Changeset: 41541097533a Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/41541097533a Merge Changeset: af6244ba81b6 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/af6244ba81b6 Added tag jdk8-b110 for changeset 41541097533a ! .hgtags From john.coomes at oracle.com Thu Oct 3 11:20:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:20:37 +0000 Subject: hg: hsx/hotspot-main/nashorn: 21 new changesets Message-ID: <20131003182103.5A03162D16@hg.openjdk.java.net> Changeset: 1971c2d770ae Author: sundar Date: 2013-09-18 13:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1971c2d770ae 8024972: for (LeftHandSideExpression in Expression) crashes the compiler Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8024972.js + test/script/basic/JDK-8024972.js.EXPECTED Changeset: a62172fe5bae Author: sundar Date: 2013-09-18 16:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a62172fe5bae 8024973: Using a different ScriptContext with a CompiledScript results in ScriptException Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Source.java ! test/script/trusted/JDK-8008305.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: f954d3f4d192 Author: sundar Date: 2013-09-19 13:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f954d3f4d192 8025048: true as case label results in ClassCastException Reviewed-by: lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025048-2.js + test/script/basic/JDK-8025048.js Changeset: 740b1133f1b6 Author: hannesw Date: 2013-09-19 15:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/740b1133f1b6 8023154: compileAllTests fails with: 2 tests failed to compile Reviewed-by: sundar, jlaskey ! make/build-benchmark.xml ! make/build.xml ! make/project.properties Changeset: 821b0b610861 Author: sundar Date: 2013-09-19 21:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/821b0b610861 8025080: Object literal getter, setter function with number format property name results in ClassFormatError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8025080.js + test/script/basic/JDK-8025080.js.EXPECTED ! test/script/basic/parser/objectLitExpr.js.EXPECTED Changeset: 18d64bc4937d Author: sundar Date: 2013-09-19 23:48 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/18d64bc4937d 8025090: 'while' statement with 'test' using var before being declared in body results in VerifyError Reviewed-by: jlaskey ! src/jdk/nashorn/internal/ir/WhileNode.java + test/script/basic/JDK-8025090.js Changeset: 195be8ca5c97 Author: sundar Date: 2013-09-20 12:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/195be8ca5c97 8025111: undefined or null 'with' expression in empty with block should throw TypeError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8025111.js Changeset: fa491b75d3e4 Author: hannesw Date: 2013-09-20 12:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fa491b75d3e4 8022587: ClassCache is not optimal and leaks Source instances Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java Changeset: 13210550765c Author: lana Date: 2013-09-20 19:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/13210550765c Merge Changeset: 279f47b353f3 Author: sundar Date: 2013-09-20 20:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/279f47b353f3 8025147: Trailing comma is not allowed in JSONArray and JSONObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8025147.js + test/script/basic/JDK-8025147.js.EXPECTED Changeset: 16b6db9f7225 Author: sundar Date: 2013-09-20 22:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/16b6db9f7225 8025149: JSON.stringify does not handle 'space' argument as per the spec. Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeJSON.java + test/script/basic/JDK-8025149.js + test/script/basic/JDK-8025149.js.EXPECTED Changeset: b8d9a63578e2 Author: hannesw Date: 2013-09-21 10:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b8d9a63578e2 8025163: Date methods should not return -0 Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8025163.js + test/script/basic/JDK-8025163.js.EXPECTED Changeset: 8f6304373671 Author: sundar Date: 2013-09-23 14:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8f6304373671 Merge Changeset: c5475f5d4647 Author: sundar Date: 2013-09-24 20:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c5475f5d4647 8025312: parseInt should convert 'radix' argument to ToInt32 even if empty string is parsed Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8025312.js + test/script/basic/JDK-8025312.js.EXPECTED Changeset: 754ecd62bde3 Author: sundar Date: 2013-09-25 08:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/754ecd62bde3 8025325: parseFloat does not handle '.' in exponent part Reviewed-by: hannesw ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8025325.js + test/script/basic/JDK-8025325.js.EXPECTED Changeset: 2f8f99e5ed76 Author: hannesw Date: 2013-09-25 16:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2f8f99e5ed76 8025434: RegExp lastIndex can exceed int range Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025434.js Changeset: 712f5e31739b Author: hannesw Date: 2013-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/712f5e31739b 8025197: String replace method fails with regexp /$/gi Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025197.js + test/script/basic/JDK-8025197.js.EXPECTED Changeset: 23958764f866 Author: hannesw Date: 2013-09-26 11:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/23958764f866 8025486: RegExp constructor arguments are not evaluated in right order Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025486.js + test/script/basic/JDK-8025486.js.EXPECTED Changeset: f1f027907a69 Author: sundar Date: 2013-09-26 16:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f1f027907a69 Merge Changeset: d49a8c2173f5 Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d49a8c2173f5 Merge Changeset: 75fd3486e584 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/75fd3486e584 Added tag jdk8-b110 for changeset d49a8c2173f5 ! .hgtags From ioi.lam at oracle.com Thu Oct 3 11:49:00 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 03 Oct 2013 11:49:00 -0700 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: <524DBC1C.6020207@oracle.com> Vote: yes On 10/01/2013 11:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From ysr1729 at gmail.com Thu Oct 3 12:02:05 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 3 Oct 2013 12:02:05 -0700 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: Vote: yes. -- ramki (Openjdk: ysr) On Tue, Oct 1, 2013 at 11:37 PM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From stefan.karlsson at oracle.com Thu Oct 3 12:40:28 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 03 Oct 2013 21:40:28 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages Message-ID: <524DC82C.5000800@oracle.com> Please review this change to turn off transparent huge pages by default. http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: TBD1, TBD2 thanks, StefanK From ysr1729 at gmail.com Thu Oct 3 13:01:57 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 3 Oct 2013 13:01:57 -0700 Subject: RFR (S): 8024087: Remove dead JVM_{Get, Set}PrimitiveFieldValues functions In-Reply-To: <524B674A.8080201@oracle.com> References: <524A16C0.4080606@oracle.com> <524B674A.8080201@oracle.com> Message-ID: The changes look good to me too. -- ramki (ysr) On Tue, Oct 1, 2013 at 5:22 PM, Mikael Vidstedt wrote: > > Coleen/Christian/Chris/Dmitry - Thanks for the reviews. > > Since this is only relevant on pre-1.4 JDKs I actually really think nobody > depends on this. > > I noticed that I needed one small additional change in nativeLookup.cpp - > the struct is iterated over in the function just below > (lookup_special_native) and the start index was previously initialized to 2 > for jdk1.4+, skipping the first two entries in the array. With that change > in place everything works as expected. > > I uploaded a webrev with that change included for the curious: > > http://cr.openjdk.java.net/~mikael/webrevs/8024087/webrev.01/webrev/ > > Cheers, > Mikael > > > On 2013-09-30 18:27, Christian Thalinger wrote: >> >> 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 >>> > From alejandro.murillo at oracle.com Thu Oct 3 13:10:50 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 03 Oct 2013 20:10:50 +0000 Subject: hg: hsx/jdk7u/hotspot: 8025861: Set minor version for hotspot in 7u60 to 60 and build number to b01 Message-ID: <20131003201119.6515962D2F@hg.openjdk.java.net> Changeset: c50928ab9548 Author: amurillo Date: 2013-10-03 06:04 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c50928ab9548 8025861: Set minor version for hotspot in 7u60 to 60 and build number to b01 Reviewed-by: stefank, sla ! make/hotspot_version From christian.thalinger at oracle.com Thu Oct 3 15:02:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 15:02:24 -0700 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D036BFF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036BFF@DEWDFEMB12A.global.corp.sap> Message-ID: <9A4AE1D4-E4DF-462A-B5C9-F4C8A94C5823@oracle.com> Before I start to review this I've assigned the bug to you, Goetz: https://bugs.openjdk.java.net/browse/JDK-8003854 On Oct 2, 2013, at 6:49 AM, "Lindenmaier, Goetz" wrote: > Hi, > > we extended C2 by what we call lateExpand. LateExpand expands nodes > after register allocation. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Some nodes can not be expanded during matching. E.g., register > allocation might not be able to deal with the resulting pattern. To > allow better scheduling in such cases, we introduce lateExpand which > runs after register allocation. Whether and how nodes are expanded is > specified in the ad-file. See block.cpp for a detailed > documentation. We use this for some nodes on ppc, and extensively on > ia64. > For an example, see the webrev. > > We added some utility functions in node.hpp and block.hpp used by > PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, > MachConstantBaseNode gets the two new functions, as we need to > late expand it. > > To skip the walk over the IR if no lateExpand is needed, we use > Matcher::require_late_expand set in the ad file. This ends up in > ad_.cpp, thus can not be evaluated by the C++ compiler. If you > agree, I would use a "const bool EnableLateExpand" in > globalDefinitions_.hpp. (There is no suitable c2__.hpp > file). > > We allready mailed a webrev with this change after last year's > JavaOne, but there was no discussion on it. > Again, this change is 'L', but the code is not used on other > platforms than PPC64 (so far). So the impact on those platforms > should be minimal. > > Please review and test this change. > > Thanks and best regards, > Goetz. From vladimir.danushevsky at oracle.com Thu Oct 3 14:43:24 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 03 Oct 2013 21:43:24 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131003214338.D184762D45@hg.openjdk.java.net> Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - 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: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/100614790c1e Merge From vladimir.kozlov at oracle.com Thu Oct 3 16:41:41 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 16:41:41 -0700 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: <524E00B5.7060005@oracle.com> Assembler and compilers changes are good. thanks, Vladimir On 10/2/13 5:28 AM, Mikael Gerdin wrote: > Hi > > Please review my fix for the issue discussed in the "G1 question: > concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing > list. > > I'd like someone from the compiler (and runtime? the interpreter uses > macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set the card to > "clean" and proceeded to scan the card but the java thread may have seen > the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and the reading > of the previous card value. > * Modify the code for handling young regions so that all writes to young > regions can skip the fence (since it will never be needed for such > writes). This introduces a new value in the card table for G1 which > indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of 1-1.5% > (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by > redesigning G1's post barrier but there is not enough time to do that > for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt > > Unfortunately the JIRA issue is not externally visible, but the major > parts of the discussions about this are present in the mailing list > thread. The bug mostly contains my analysis of the crashes which seems > to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 > From david.holmes at oracle.com Thu Oct 3 23:07:36 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 04 Oct 2013 06:07:36 +0000 Subject: hg: hsx/jdk7u/hotspot: 6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock Message-ID: <20131004060745.37C7062D4C@hg.openjdk.java.net> Changeset: fd506dce728a Author: dholmes Date: 2013-10-03 18:41 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/fd506dce728a 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 From jesper.wilhelmsson at oracle.com Fri Oct 4 00:01:14 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 04 Oct 2013 09:01:14 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <524DC82C.5000800@oracle.com> References: <524DC82C.5000800@oracle.com> Message-ID: <524E67BA.2020301@oracle.com> Looks good! Is there a reason to why you chose not to use SET_FLAG_ERGO when updating the flags? If not I would prefer if the macro was used. /Jesper Stefan Karlsson skrev 3/10/13 9:40 PM: > Please review this change to turn off transparent huge pages by default. > > http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ > > 8024838: Significant slowdown due to transparent huge pages > Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) > unless explicitly specified on the command line. This has the effect that large > pages are never turned on Linux unless the user has explicitly enabled any of > the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, > -XX:+UseHugeTLBFS, and -XX:+UseSHM. > Reviewed-by: TBD1, TBD2 > > thanks, > StefanK From thomas.schatzl at oracle.com Fri Oct 4 00:24:20 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 04 Oct 2013 09:24:20 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <524DC82C.5000800@oracle.com> References: <524DC82C.5000800@oracle.com> Message-ID: <1380871460.2683.4.camel@cirrus> Hi, On Thu, 2013-10-03 at 21:40 +0200, Stefan Karlsson wrote: > Please review this change to turn off transparent huge pages by default. > > http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ In os_linux.cpp there is a typo in the comment: "UseTranpsparentHugePages" instead . Otherwise, looks good, particularly I like how the change tests different VM flag combinations. Thomas From stefan.karlsson at oracle.com Fri Oct 4 01:14:16 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 04 Oct 2013 10:14:16 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <1380871460.2683.4.camel@cirrus> References: <524DC82C.5000800@oracle.com> <1380871460.2683.4.camel@cirrus> Message-ID: <524E78D8.3060704@oracle.com> On 2013-10-04 09:24, Thomas Schatzl wrote: > Hi, > > On Thu, 2013-10-03 at 21:40 +0200, Stefan Karlsson wrote: >> Please review this change to turn off transparent huge pages by default. >> >> http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ > In os_linux.cpp there is a typo in the comment: > "UseTranpsparentHugePages" instead . Good catch. > > Otherwise, looks good, particularly I like how the change tests > different VM flag combinations. Thanks, Thomas. StefanK > > Thomas > From stefan.karlsson at oracle.com Fri Oct 4 01:17:41 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 04 Oct 2013 10:17:41 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <524E67BA.2020301@oracle.com> References: <524DC82C.5000800@oracle.com> <524E67BA.2020301@oracle.com> Message-ID: <524E79A5.7040508@oracle.com> On 2013-10-04 09:01, Jesper Wilhelmsson wrote: > Looks good! Thanks, Jesper. > > Is there a reason to why you chose not to use SET_FLAG_ERGO when > updating the flags? If not I would prefer if the macro was used. I wanted to minimize the risk that some other code looking at the large pages flags would fail if I started to use the SET_FLAG macros. thanks, StefanK > /Jesper > > > Stefan Karlsson skrev 3/10/13 9:40 PM: >> Please review this change to turn off transparent huge pages by default. >> >> http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ >> >> 8024838: Significant slowdown due to transparent huge pages >> Summary: Don't turn on transparent huge pages >> (-XX:+UseTransparentHugePages) >> unless explicitly specified on the command line. This has the effect >> that large >> pages are never turned on Linux unless the user has explicitly >> enabled any of >> the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, >> -XX:+UseHugeTLBFS, and -XX:+UseSHM. >> Reviewed-by: TBD1, TBD2 >> >> thanks, >> StefanK From mikael.gerdin at oracle.com Fri Oct 4 01:32:43 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 04 Oct 2013 10:32:43 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: References: <524C1186.5070105@oracle.com> Message-ID: <524E7D2B.90106@oracle.com> Roland On 2013-10-03 11:19, Roland Westrelin wrote: >> I'd like someone from the compiler (and runtime? the interpreter uses macroAssembler_*, right?) teams to at least look at the changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp > > That looks good to me. > Maybe a comment that says you're using Op_MemBarVolatile because you need a StoreLoad. Will do, thanks for Reviewing. /Mikael > > Roland. > From david.holmes at oracle.com Fri Oct 4 02:15:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 19:15:04 +1000 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: <524E8718.1080009@oracle.com> Hi Mikael, src/cpu/sparc/vm/c1_Runtime1_sparc.cpp: I don't quite follow the logic for this: __ set(rs, cardtable); // cardtable := __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] + __ cmp_and_br_short(tmp, G1SATBCardTableModRefBS::g1_young_card_val(), Assembler::equal, Assembler::pt, young_card); + + __ membar(Assembler::Membar_mask_bits(Assembler::StoreLoad)); + __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] You load the cardtable with no barrier, checks its value and if it seems "wrong" (?) you then issue the storeload barrier and try again. Why not just insert the storeload barrier between the store and the load? Similar comment for src/cpu/sparc/vm/macroAssembler_sparc.cpp. --- src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp: void G1SATBCardTableLoggingModRefBS::write_ref_field_work(void* field, oop new_val) { ! volatile jbyte* byte = byte_for(field); ! if (*byte == g1_young_gen) { ! return; ! } ! OrderAccess::storeload(); where is the store that you are ordering with? Similarly: ! for (; byte <= last_byte; byte++) { ! if (*byte == g1_young_gen) { ! continue; ! } ! OrderAccess::storeload(); if (*byte != dirty_card) { *byte = dirty_card; jt->dirty_card_queue().enqueue(byte); } } the store seems to be after the barrier ? Cheers, David On 2/10/2013 10:28 PM, Mikael Gerdin wrote: > Hi > > Please review my fix for the issue discussed in the "G1 question: > concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing > list. > > I'd like someone from the compiler (and runtime? the interpreter uses > macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set the card to > "clean" and proceeded to scan the card but the java thread may have seen > the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and the reading > of the previous card value. > * Modify the code for handling young regions so that all writes to young > regions can skip the fence (since it will never be needed for such > writes). This introduces a new value in the card table for G1 which > indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of 1-1.5% > (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by > redesigning G1's post barrier but there is not enough time to do that > for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt > > Unfortunately the JIRA issue is not externally visible, but the major > parts of the discussions about this are present in the mailing list > thread. The bug mostly contains my analysis of the crashes which seems > to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 > From dmitry.samersoff at oracle.com Fri Oct 4 03:24:56 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Fri, 04 Oct 2013 10:24:56 +0000 Subject: hg: hsx/jdk7u/hotspot: 8019396: SA-JDI: OSThread class initialization throws an exception Message-ID: <20131004102525.5581662D69@hg.openjdk.java.net> Changeset: cc83359f5e5e Author: dsamersoff Date: 2013-10-04 12:08 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/cc83359f5e5e 8019396: SA-JDI: OSThread class initialization throws an exception Summary: Method s.j.h.r.OSThread.initialize throws a an exception Reviewed-by: dholmes, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java From mikael.gerdin at oracle.com Fri Oct 4 05:17:42 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 04 Oct 2013 14:17:42 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524E8718.1080009@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> Message-ID: <524EB1E6.5070001@oracle.com> David, On 10/04/2013 11:15 AM, David Holmes wrote: > Hi Mikael, > > src/cpu/sparc/vm/c1_Runtime1_sparc.cpp: > > I don't quite follow the logic for this: > > __ set(rs, cardtable); // cardtable := > __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] > > + __ cmp_and_br_short(tmp, > G1SATBCardTableModRefBS::g1_young_card_val(), Assembler::equal, > Assembler::pt, young_card); > + > + __ membar(Assembler::Membar_mask_bits(Assembler::StoreLoad)); > + __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] > > You load the cardtable with no barrier, checks its value and if it seems > "wrong" (?) you then issue the storeload barrier and try again. Why not > just insert the storeload barrier between the store and the load? > > Similar comment for src/cpu/sparc/vm/macroAssembler_sparc.cpp. > > --- > > src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp: > > void > G1SATBCardTableLoggingModRefBS::write_ref_field_work(void* field, > oop new_val) { > ! volatile jbyte* byte = byte_for(field); > ! if (*byte == g1_young_gen) { > ! return; > ! } > ! OrderAccess::storeload(); > > where is the store that you are ordering with? > > Similarly: > > ! for (; byte <= last_byte; byte++) { > ! if (*byte == g1_young_gen) { > ! continue; > ! } > ! OrderAccess::storeload(); > if (*byte != dirty_card) { > *byte = dirty_card; > jt->dirty_card_queue().enqueue(byte); > } > } > > the store seems to be after the barrier ? Let me take one step back and describe the situation more thouroghly. The post-barrier for G1 has the following structure before my change (o is a java object, f is a field in o and x is another java object) o.f = x if (*card_for(o) == dirty) then goto done *card_for(o) = dirty enqueue(card_for(o)) done: The memory ordering problem can occur between the store o.f = x and the read of *card_for(o) This is because the concurrent refinement thread will set a card to "clean" before it starts scanning the card for references, but that store is not guaranteed to be visible to the thread executing the post-barrier. So if the CPU re-orders the load from card_for(o) to before the write of o.f the refinement thread may have scanned past the address of o.f but the application thread sees the stale "dirty" value and skips the barrier. The simple fix for this race is then to insert a storeload between the store and the load: o.f = x #StoreLoad if (*card_for(o) == dirty) then goto done *card_for(o) = dirty enqueue(card_for(o)) done: Inserting the storeload is too expensive since this code is in the object field write fast-path. So I introduced a way to exclude some writes by relying on a new card value which I know is not suspect to concurrent updates: o.f = x if (*card_for(o) == g1_young) then goto done #StoreLoad (because I can only rely on the value "dirty" if the store was committed before the following read) if (*card_for(o) == dirty) then goto done *card_for(o) = dirty enqueue(card_for(o)) done: I hope this clarifies the issue and the reasoning behind my changes. /Mikael > > Cheers, > David > > On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >> Hi >> >> Please review my fix for the issue discussed in the "G1 question: >> concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing >> list. >> >> I'd like someone from the compiler (and runtime? the interpreter uses >> macroAssembler_*, right?) teams to at least look at the changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may miss object >> references in a dirty card. >> The problem arises if the CPU re-orders the load of the old card value >> (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set the card to >> "clean" and proceeded to scan the card but the java thread may have seen >> the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and the reading >> of the previous card value. >> * Modify the code for handling young regions so that all writes to young >> regions can skip the fence (since it will never be needed for such >> writes). This introduces a new value in the card table for G1 which >> indicates a young region. >> >> Performance impact: >> * This fix has a negative throughput performance impact of 1-1.5% >> (tested on x86-AMD x86-Intel and SPARC). >> * We may want to try to get rid of this race at some point by >> redesigning G1's post barrier but there is not enough time to do that >> for JDK8. >> >> Performance numbers for x86 platforms can be seen here: >> http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt >> >> Unfortunately the JIRA issue is not externally visible, but the major >> parts of the discussions about this are present in the mailing list >> thread. The bug mostly contains my analysis of the crashes which seems >> to have been caused by this bug. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 >> From david.holmes at oracle.com Fri Oct 4 05:32:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 22:32:59 +1000 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524EB1E6.5070001@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> Message-ID: <524EB57B.7060609@oracle.com> Hi Mikael, Thanks for the explanation. See inline ... On 4/10/2013 10:17 PM, Mikael Gerdin wrote: > David, > > On 10/04/2013 11:15 AM, David Holmes wrote: >> Hi Mikael, >> >> src/cpu/sparc/vm/c1_Runtime1_sparc.cpp: >> >> I don't quite follow the logic for this: >> >> __ set(rs, cardtable); // cardtable := > base> >> __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] >> >> + __ cmp_and_br_short(tmp, >> G1SATBCardTableModRefBS::g1_young_card_val(), Assembler::equal, >> Assembler::pt, young_card); >> + >> + __ membar(Assembler::Membar_mask_bits(Assembler::StoreLoad)); >> + __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] >> >> You load the cardtable with no barrier, checks its value and if it seems >> "wrong" (?) you then issue the storeload barrier and try again. Why not >> just insert the storeload barrier between the store and the load? >> >> Similar comment for src/cpu/sparc/vm/macroAssembler_sparc.cpp. >> I can see how what you explained fits in here but ... >> --- >> >> src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp: >> >> void >> G1SATBCardTableLoggingModRefBS::write_ref_field_work(void* field, >> oop new_val) { >> ! volatile jbyte* byte = byte_for(field); >> ! if (*byte == g1_young_gen) { >> ! return; >> ! } >> ! OrderAccess::storeload(); >> >> where is the store that you are ordering with? not here - where is the store? >> Similarly: >> >> ! for (; byte <= last_byte; byte++) { >> ! if (*byte == g1_young_gen) { >> ! continue; >> ! } >> ! OrderAccess::storeload(); >> if (*byte != dirty_card) { >> *byte = dirty_card; >> jt->dirty_card_queue().enqueue(byte); >> } >> } >> >> the store seems to be after the barrier ? Nor here - which store and load are we ordering? Thanks, David ----- > > Let me take one step back and describe the situation more thouroghly. > The post-barrier for G1 has the following structure before my change > (o is a java object, f is a field in o and x is another java object) > > o.f = x > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > The memory ordering problem can occur between the store > o.f = x and the read of *card_for(o) > This is because the concurrent refinement thread will set a card to > "clean" before it starts scanning the card for references, but that > store is not guaranteed to be visible to the thread executing the > post-barrier. > So if the CPU re-orders the load from card_for(o) to before the write of > o.f the refinement thread may have scanned past the address of o.f but > the application thread sees the stale "dirty" value and skips the barrier. > > > The simple fix for this race is then to insert a storeload between the > store and the load: > o.f = x > #StoreLoad > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > Inserting the storeload is too expensive since this code is in the > object field write fast-path. So I introduced a way to exclude some > writes by relying on a new card value which I know is not suspect to > concurrent updates: > > o.f = x > if (*card_for(o) == g1_young) then goto done > #StoreLoad (because I can only rely on the value "dirty" if the store > was committed before the following read) > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > I hope this clarifies the issue and the reasoning behind my changes. > > /Mikael > >> >> Cheers, >> David >> >> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >>> Hi >>> >>> Please review my fix for the issue discussed in the "G1 question: >>> concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing >>> list. >>> >>> I'd like someone from the compiler (and runtime? the interpreter uses >>> macroAssembler_*, right?) teams to at least look at the changes to: >>> macroAssembler_*.cpp >>> c1_Runtime_*.cpp >>> graphKit.cpp >>> >>> Problem description: >>> G1 has a race where the concurrent refinement thread may miss object >>> references in a dirty card. >>> The problem arises if the CPU re-orders the load of the old card value >>> (which G1 checks to determine if it can skip the barrier) >>> before the store to the actual object. >>> If that occurs the concurrent refinement thread may have set the card to >>> "clean" and proceeded to scan the card but the java thread may have seen >>> the "dirty" value and skipped the post barrier. >>> >>> Suggested fix: >>> * Add a memory fence between the store to a java object and the reading >>> of the previous card value. >>> * Modify the code for handling young regions so that all writes to young >>> regions can skip the fence (since it will never be needed for such >>> writes). This introduces a new value in the card table for G1 which >>> indicates a young region. >>> >>> Performance impact: >>> * This fix has a negative throughput performance impact of 1-1.5% >>> (tested on x86-AMD x86-Intel and SPARC). >>> * We may want to try to get rid of this race at some point by >>> redesigning G1's post barrier but there is not enough time to do that >>> for JDK8. >>> >>> Performance numbers for x86 platforms can be seen here: >>> http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt >>> >>> Unfortunately the JIRA issue is not externally visible, but the major >>> parts of the discussions about this are present in the mailing list >>> thread. The bug mostly contains my analysis of the crashes which seems >>> to have been caused by this bug. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 >>> >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 >>> > From mikael.gerdin at oracle.com Fri Oct 4 06:03:05 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 04 Oct 2013 15:03:05 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524EB57B.7060609@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> <524EB57B.7060609@oracle.com> Message-ID: <524EBC89.5000300@oracle.com> David, On 10/04/2013 02:32 PM, David Holmes wrote: > Hi Mikael, > > Thanks for the explanation. See inline ... > > On 4/10/2013 10:17 PM, Mikael Gerdin wrote: >> David, >> >> On 10/04/2013 11:15 AM, David Holmes wrote: >>> Hi Mikael, >>> >>> src/cpu/sparc/vm/c1_Runtime1_sparc.cpp: >>> >>> I don't quite follow the logic for this: >>> >>> __ set(rs, cardtable); // cardtable := >> base> >>> __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] >>> >>> + __ cmp_and_br_short(tmp, >>> G1SATBCardTableModRefBS::g1_young_card_val(), Assembler::equal, >>> Assembler::pt, young_card); >>> + >>> + __ membar(Assembler::Membar_mask_bits(Assembler::StoreLoad)); >>> + __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] >>> >>> You load the cardtable with no barrier, checks its value and if it seems >>> "wrong" (?) you then issue the storeload barrier and try again. Why not >>> just insert the storeload barrier between the store and the load? >>> >>> Similar comment for src/cpu/sparc/vm/macroAssembler_sparc.cpp. >>> > > I can see how what you explained fits in here but ... > >>> --- >>> >>> src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp: >>> >>> void >>> G1SATBCardTableLoggingModRefBS::write_ref_field_work(void* field, >>> oop new_val) { >>> ! volatile jbyte* byte = byte_for(field); >>> ! if (*byte == g1_young_gen) { >>> ! return; >>> ! } >>> ! OrderAccess::storeload(); >>> >>> where is the store that you are ordering with? > > not here - where is the store? write_ref_field_work() and invalidate() are the c++ implementation of the write barrier. The store in this case is done in a calling frame, the call path looks something like: G1SATBCardTableLoggingModRefBS::write_ref_field_work BarrierSet::write_ref_field update_barrier_set oop_store The store you are looking for is the encode_store_heap_oop here: template inline void oop_store(T* p, oop v) { if (always_do_update_barrier) { oop_store((volatile T*)p, v); } else { update_barrier_set_pre(p, v); oopDesc::encode_store_heap_oop(p, v); update_barrier_set((void*)p, v); // cast away type } } > >>> Similarly: >>> >>> ! for (; byte <= last_byte; byte++) { >>> ! if (*byte == g1_young_gen) { >>> ! continue; >>> ! } >>> ! OrderAccess::storeload(); >>> if (*byte != dirty_card) { >>> *byte = dirty_card; >>> jt->dirty_card_queue().enqueue(byte); >>> } >>> } >>> >>> the store seems to be after the barrier ? > > Nor here - which store and load are we ordering? In the case of invalidate() the call path is for example: G1SATBCardTableLoggingModRefBS::invalidate G1SATBCardTableLoggingModRefBS::write_ref_array_work BarrierSet::write_ref_array ObjArrayKlass::do_copy where the writes you are looking for are in Copy::conjoint_oops_atomic or in the inline copy loop. /Mikael > > Thanks, > David > ----- > >> >> Let me take one step back and describe the situation more thouroghly. >> The post-barrier for G1 has the following structure before my change >> (o is a java object, f is a field in o and x is another java object) >> >> o.f = x >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> The memory ordering problem can occur between the store >> o.f = x and the read of *card_for(o) >> This is because the concurrent refinement thread will set a card to >> "clean" before it starts scanning the card for references, but that >> store is not guaranteed to be visible to the thread executing the >> post-barrier. >> So if the CPU re-orders the load from card_for(o) to before the write of >> o.f the refinement thread may have scanned past the address of o.f but >> the application thread sees the stale "dirty" value and skips the >> barrier. >> >> >> The simple fix for this race is then to insert a storeload between the >> store and the load: >> o.f = x >> #StoreLoad >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> Inserting the storeload is too expensive since this code is in the >> object field write fast-path. So I introduced a way to exclude some >> writes by relying on a new card value which I know is not suspect to >> concurrent updates: >> >> o.f = x >> if (*card_for(o) == g1_young) then goto done >> #StoreLoad (because I can only rely on the value "dirty" if the store >> was committed before the following read) >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> I hope this clarifies the issue and the reasoning behind my changes. >> >> /Mikael >> >>> >>> Cheers, >>> David >>> >>> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >>>> Hi >>>> >>>> Please review my fix for the issue discussed in the "G1 question: >>>> concurrent cleaning of dirty cards" thread on the hotspot-gc-dev >>>> mailing >>>> list. >>>> >>>> I'd like someone from the compiler (and runtime? the interpreter uses >>>> macroAssembler_*, right?) teams to at least look at the changes to: >>>> macroAssembler_*.cpp >>>> c1_Runtime_*.cpp >>>> graphKit.cpp >>>> >>>> Problem description: >>>> G1 has a race where the concurrent refinement thread may miss object >>>> references in a dirty card. >>>> The problem arises if the CPU re-orders the load of the old card value >>>> (which G1 checks to determine if it can skip the barrier) >>>> before the store to the actual object. >>>> If that occurs the concurrent refinement thread may have set the >>>> card to >>>> "clean" and proceeded to scan the card but the java thread may have >>>> seen >>>> the "dirty" value and skipped the post barrier. >>>> >>>> Suggested fix: >>>> * Add a memory fence between the store to a java object and the reading >>>> of the previous card value. >>>> * Modify the code for handling young regions so that all writes to >>>> young >>>> regions can skip the fence (since it will never be needed for such >>>> writes). This introduces a new value in the card table for G1 which >>>> indicates a young region. >>>> >>>> Performance impact: >>>> * This fix has a negative throughput performance impact of 1-1.5% >>>> (tested on x86-AMD x86-Intel and SPARC). >>>> * We may want to try to get rid of this race at some point by >>>> redesigning G1's post barrier but there is not enough time to do that >>>> for JDK8. >>>> >>>> Performance numbers for x86 platforms can be seen here: >>>> http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt >>>> >>>> Unfortunately the JIRA issue is not externally visible, but the major >>>> parts of the discussions about this are present in the mailing list >>>> thread. The bug mostly contains my analysis of the crashes which seems >>>> to have been caused by this bug. >>>> >>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 >>>> >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 >>>> >> From bengt.rutisson at oracle.com Fri Oct 4 06:22:28 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 04 Oct 2013 15:22:28 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <524DC82C.5000800@oracle.com> References: <524DC82C.5000800@oracle.com> Message-ID: <524EC114.6070901@oracle.com> Stefan, Looks good. Bengt On 10/3/13 9:40 PM, Stefan Karlsson wrote: > Please review this change to turn off transparent huge pages by default. > > http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ > > 8024838: Significant slowdown due to transparent huge pages > Summary: Don't turn on transparent huge pages > (-XX:+UseTransparentHugePages) unless explicitly specified on the > command line. This has the effect that large pages are never turned on > Linux unless the user has explicitly enabled any of the large pages > flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, > -XX:+UseHugeTLBFS, and -XX:+UseSHM. > Reviewed-by: TBD1, TBD2 > > thanks, > StefanK From vitalyd at gmail.com Fri Oct 4 06:32:22 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 4 Oct 2013 09:32:22 -0400 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524EB1E6.5070001@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> Message-ID: Mikael, What if you were to read the card value before the store and then check if it's clean and mark it dirty + enqueue? This would be a loadstore fence which can be noop in some archs. Or am I missing something? Thanks Sent from my phone On Oct 4, 2013 8:18 AM, "Mikael Gerdin" wrote: > David, > > On 10/04/2013 11:15 AM, David Holmes wrote: > >> Hi Mikael, >> >> src/cpu/sparc/vm/c1_Runtime1_**sparc.cpp: >> >> I don't quite follow the logic for this: >> >> __ set(rs, cardtable); // cardtable := > base> >> __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] >> >> + __ cmp_and_br_short(tmp, >> G1SATBCardTableModRefBS::g1_**young_card_val(), Assembler::equal, >> Assembler::pt, young_card); >> + >> + __ membar(Assembler::Membar_mask_**bits(Assembler::StoreLoad)); >> + __ ldub(addr, cardtable, tmp); // tmp := [addr + cardtable] >> >> You load the cardtable with no barrier, checks its value and if it seems >> "wrong" (?) you then issue the storeload barrier and try again. Why not >> just insert the storeload barrier between the store and the load? >> >> Similar comment for src/cpu/sparc/vm/**macroAssembler_sparc.cpp. >> >> --- >> >> src/share/vm/gc_**implementation/g1/**g1SATBCardTableModRefBS.cpp: >> >> void >> G1SATBCardTableLoggingModRefBS**::write_ref_field_work(void* field, >> oop new_val) { >> ! volatile jbyte* byte = byte_for(field); >> ! if (*byte == g1_young_gen) { >> ! return; >> ! } >> ! OrderAccess::storeload(); >> >> where is the store that you are ordering with? >> >> Similarly: >> >> ! for (; byte <= last_byte; byte++) { >> ! if (*byte == g1_young_gen) { >> ! continue; >> ! } >> ! OrderAccess::storeload(); >> if (*byte != dirty_card) { >> *byte = dirty_card; >> jt->dirty_card_queue().**enqueue(byte); >> } >> } >> >> the store seems to be after the barrier ? >> > > > Let me take one step back and describe the situation more thouroghly. > The post-barrier for G1 has the following structure before my change > (o is a java object, f is a field in o and x is another java object) > > o.f = x > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > The memory ordering problem can occur between the store > o.f = x and the read of *card_for(o) > This is because the concurrent refinement thread will set a card to > "clean" before it starts scanning the card for references, but that store > is not guaranteed to be visible to the thread executing the post-barrier. > So if the CPU re-orders the load from card_for(o) to before the write of > o.f the refinement thread may have scanned past the address of o.f but the > application thread sees the stale "dirty" value and skips the barrier. > > > The simple fix for this race is then to insert a storeload between the > store and the load: > o.f = x > #StoreLoad > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > Inserting the storeload is too expensive since this code is in the object > field write fast-path. So I introduced a way to exclude some writes by > relying on a new card value which I know is not suspect to concurrent > updates: > > o.f = x > if (*card_for(o) == g1_young) then goto done > #StoreLoad (because I can only rely on the value "dirty" if the store was > committed before the following read) > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > I hope this clarifies the issue and the reasoning behind my changes. > > /Mikael > > >> Cheers, >> David >> >> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >> >>> Hi >>> >>> Please review my fix for the issue discussed in the "G1 question: >>> concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing >>> list. >>> >>> I'd like someone from the compiler (and runtime? the interpreter uses >>> macroAssembler_*, right?) teams to at least look at the changes to: >>> macroAssembler_*.cpp >>> c1_Runtime_*.cpp >>> graphKit.cpp >>> >>> Problem description: >>> G1 has a race where the concurrent refinement thread may miss object >>> references in a dirty card. >>> The problem arises if the CPU re-orders the load of the old card value >>> (which G1 checks to determine if it can skip the barrier) >>> before the store to the actual object. >>> If that occurs the concurrent refinement thread may have set the card to >>> "clean" and proceeded to scan the card but the java thread may have seen >>> the "dirty" value and skipped the post barrier. >>> >>> Suggested fix: >>> * Add a memory fence between the store to a java object and the reading >>> of the previous card value. >>> * Modify the code for handling young regions so that all writes to young >>> regions can skip the fence (since it will never be needed for such >>> writes). This introduces a new value in the card table for G1 which >>> indicates a young region. >>> >>> Performance impact: >>> * This fix has a negative throughput performance impact of 1-1.5% >>> (tested on x86-AMD x86-Intel and SPARC). >>> * We may want to try to get rid of this race at some point by >>> redesigning G1's post barrier but there is not enough time to do that >>> for JDK8. >>> >>> Performance numbers for x86 platforms can be seen here: >>> http://cr.openjdk.java.net/~**mgerdin/8014555/perf.txt >>> >>> Unfortunately the JIRA issue is not externally visible, but the major >>> parts of the discussions about this are present in the mailing list >>> thread. The bug mostly contains my analysis of the crashes which seems >>> to have been caused by this bug. >>> >>> Bug link: https://bugs.openjdk.java.net/**browse/JDK-8014555 >>> >>> Webrev: http://cr.openjdk.java.net/~**mgerdin/8014555/webrev.0 >>> >>> > From goetz.lindenmaier at sap.com Fri Oct 4 10:48:13 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 4 Oct 2013 17:48:13 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <9A4AE1D4-E4DF-462A-B5C9-F4C8A94C5823@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D036BFF@DEWDFEMB12A.global.corp.sap> <9A4AE1D4-E4DF-462A-B5C9-F4C8A94C5823@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D039C50@DEWDFEMB12A.global.corp.sap> Hi Christian, thanks for assigning that to me. Can/may I change the title of the bug? I would like to put in the 'PPC (part 115)' marker. Have fun reviewing ;) best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Friday, October 04, 2013 12:02 AM To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. Before I start to review this I've assigned the bug to you, Goetz: https://bugs.openjdk.java.net/browse/JDK-8003854 On Oct 2, 2013, at 6:49 AM, "Lindenmaier, Goetz" wrote: > Hi, > > we extended C2 by what we call lateExpand. LateExpand expands nodes > after register allocation. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Some nodes can not be expanded during matching. E.g., register > allocation might not be able to deal with the resulting pattern. To > allow better scheduling in such cases, we introduce lateExpand which > runs after register allocation. Whether and how nodes are expanded is > specified in the ad-file. See block.cpp for a detailed > documentation. We use this for some nodes on ppc, and extensively on > ia64. > For an example, see the webrev. > > We added some utility functions in node.hpp and block.hpp used by > PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, > MachConstantBaseNode gets the two new functions, as we need to > late expand it. > > To skip the walk over the IR if no lateExpand is needed, we use > Matcher::require_late_expand set in the ad file. This ends up in > ad_.cpp, thus can not be evaluated by the C++ compiler. If you > agree, I would use a "const bool EnableLateExpand" in > globalDefinitions_.hpp. (There is no suitable c2__.hpp > file). > > We allready mailed a webrev with this change after last year's > JavaOne, but there was no discussion on it. > Again, this change is 'L', but the code is not used on other > platforms than PPC64 (so far). So the impact on those platforms > should be minimal. > > Please review and test this change. > > Thanks and best regards, > Goetz. From alejandro.murillo at oracle.com Fri Oct 4 11:02:54 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 04 Oct 2013 18:02:54 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.60-b01 for changeset cc83359f5e5e Message-ID: <20131004180304.7662162D8C@hg.openjdk.java.net> Changeset: 62c54975ca01 Author: amurillo Date: 2013-10-04 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/62c54975ca01 Added tag hs24.60-b01 for changeset cc83359f5e5e ! .hgtags From vladimir.kozlov at oracle.com Fri Oct 4 11:29:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 11:29:53 -0700 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D039C50@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036BFF@DEWDFEMB12A.global.corp.sap> <9A4AE1D4-E4DF-462A-B5C9-F4C8A94C5823@oracle.com> <4295855A5C1DE049A61835A1887419CC0D039C50@DEWDFEMB12A.global.corp.sap> Message-ID: <524F0921.5000405@oracle.com> On 10/4/13 10:48 AM, Lindenmaier, Goetz wrote: > Hi Christian, > > thanks for assigning that to me. Can/may I change the title > of the bug? I would like to put in the 'PPC (part 115)' marker. You don't need to ask permission for a bug you own :) Try, if the system will not allow I will change it. Vladimir > > Have fun reviewing ;) > best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Friday, October 04, 2013 12:02 AM > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Before I start to review this I've assigned the bug to you, Goetz: > > https://bugs.openjdk.java.net/browse/JDK-8003854 > > On Oct 2, 2013, at 6:49 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> we extended C2 by what we call lateExpand. LateExpand expands nodes >> after register allocation. >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >> >> Some nodes can not be expanded during matching. E.g., register >> allocation might not be able to deal with the resulting pattern. To >> allow better scheduling in such cases, we introduce lateExpand which >> runs after register allocation. Whether and how nodes are expanded is >> specified in the ad-file. See block.cpp for a detailed >> documentation. We use this for some nodes on ppc, and extensively on >> ia64. >> For an example, see the webrev. >> >> We added some utility functions in node.hpp and block.hpp used by >> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >> MachConstantBaseNode gets the two new functions, as we need to >> late expand it. >> >> To skip the walk over the IR if no lateExpand is needed, we use >> Matcher::require_late_expand set in the ad file. This ends up in >> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >> agree, I would use a "const bool EnableLateExpand" in >> globalDefinitions_.hpp. (There is no suitable c2__.hpp >> file). >> >> We allready mailed a webrev with this change after last year's >> JavaOne, but there was no discussion on it. >> Again, this change is 'L', but the code is not used on other >> platforms than PPC64 (so far). So the impact on those platforms >> should be minimal. >> >> Please review and test this change. >> >> Thanks and best regards, >> Goetz. > From goetz.lindenmaier at sap.com Fri Oct 4 12:52:07 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 4 Oct 2013 19:52:07 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <524F0921.5000405@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D036BFF@DEWDFEMB12A.global.corp.sap> <9A4AE1D4-E4DF-462A-B5C9-F4C8A94C5823@oracle.com> <4295855A5C1DE049A61835A1887419CC0D039C50@DEWDFEMB12A.global.corp.sap> <524F0921.5000405@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D039C7D@DEWDFEMB12A.global.corp.sap> Hi, ok, that worked fine -- but not everything I can do is good, e.g. pushing changes without reviewer ;) Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, October 04, 2013 8:30 PM To: Lindenmaier, Goetz Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. On 10/4/13 10:48 AM, Lindenmaier, Goetz wrote: > Hi Christian, > > thanks for assigning that to me. Can/may I change the title > of the bug? I would like to put in the 'PPC (part 115)' marker. You don't need to ask permission for a bug you own :) Try, if the system will not allow I will change it. Vladimir > > Have fun reviewing ;) > best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Friday, October 04, 2013 12:02 AM > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Before I start to review this I've assigned the bug to you, Goetz: > > https://bugs.openjdk.java.net/browse/JDK-8003854 > > On Oct 2, 2013, at 6:49 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> we extended C2 by what we call lateExpand. LateExpand expands nodes >> after register allocation. >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >> >> Some nodes can not be expanded during matching. E.g., register >> allocation might not be able to deal with the resulting pattern. To >> allow better scheduling in such cases, we introduce lateExpand which >> runs after register allocation. Whether and how nodes are expanded is >> specified in the ad-file. See block.cpp for a detailed >> documentation. We use this for some nodes on ppc, and extensively on >> ia64. >> For an example, see the webrev. >> >> We added some utility functions in node.hpp and block.hpp used by >> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >> MachConstantBaseNode gets the two new functions, as we need to >> late expand it. >> >> To skip the walk over the IR if no lateExpand is needed, we use >> Matcher::require_late_expand set in the ad file. This ends up in >> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >> agree, I would use a "const bool EnableLateExpand" in >> globalDefinitions_.hpp. (There is no suitable c2__.hpp >> file). >> >> We allready mailed a webrev with this change after last year's >> JavaOne, but there was no discussion on it. >> Again, this change is 'L', but the code is not used on other >> platforms than PPC64 (so far). So the impact on those platforms >> should be minimal. >> >> Please review and test this change. >> >> Thanks and best regards, >> Goetz. > From john.coomes at oracle.com Fri Oct 4 17:19:16 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 05 Oct 2013 00:19:16 +0000 Subject: hg: hsx/hotspot-main/hotspot: 14 new changesets Message-ID: <20131005001947.816FE62DA2@hg.openjdk.java.net> Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp From alejandro.murillo at oracle.com Fri Oct 4 20:43:47 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 05 Oct 2013 03:43:47 +0000 Subject: hg: hsx/hsx25/hotspot: 44 new changesets Message-ID: <20131005034531.6D08462DAD@hg.openjdk.java.net> Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 24250c363d7f Author: amurillo Date: 2013-09-26 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/24250c363d7f 8025536: new hotspot build - hs25-b53 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 899ecf76b570 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/899ecf76b570 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 5b1191bf0b4b Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5b1191bf0b4b 8024677: [TESTBUG] Move tests for classes in /testlibrary Summary: Moved the tests to /testlibrary_tests and updated TEST.groups Reviewed-by: dholmes, sla ! test/TEST.groups - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java + test/testlibrary_tests/AssertsTest.java + test/testlibrary_tests/OutputAnalyzerReportingTest.java + test/testlibrary_tests/OutputAnalyzerTest.java Changeset: c1fbf21c7397 Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c1fbf21c7397 8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures Summary: Added methods for 32bit, arm, ppc, x64 and x86 Reviewed-by: zgu, hseigel, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 190899198332 Author: hseigel Date: 2013-09-26 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/190899198332 7195622: CheckUnhandledOops has limited usefulness now Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms. Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a5ac0873476c Author: zgu Date: 2013-09-27 10:08 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a5ac0873476c Merge ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/31f0118ea584 Merge Changeset: 72b7e96c1922 Author: twisti Date: 2013-09-26 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/72b7e96c1922 8024545: make develop and notproduct flag values available in product builds Reviewed-by: dholmes, kvn ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryService.cpp Changeset: c9ccd7b85f20 Author: rbackman Date: 2013-09-27 08:39 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c9ccd7b85f20 8024924: Intrinsify java.lang.Math.addExact Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + src/share/vm/opto/mathexactnode.cpp + src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/CondTest.java + test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/LoadTest.java + test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/NonConstantTest.java + test/compiler/intrinsics/mathexact/Verify.java Changeset: 510fbd28919c Author: anoll Date: 2013-09-27 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/510fbd28919c 8020151: PSR:PERF Large performance regressions when code cache is filled Summary: Code cache sweeping based on method hotness; removed speculatively disconnect Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/trace/trace.xml Changeset: a07c25e4f67e Author: adlertz Date: 2013-09-27 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a07c25e4f67e Merge ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: 1c3486050433 Author: adlertz Date: 2013-09-27 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1c3486050433 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e8e077292da3 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e8e077292da3 8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc Reviewed-by: twisti ! 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 Changeset: 303826f477c6 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/303826f477c6 8023452: TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: f2512d89ad0c Author: twisti Date: 2013-09-28 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f2512d89ad0c 8025613: clang: remove -Wno-unused-value Reviewed-by: iveresov ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp Changeset: 29bdcf12457c Author: shade Date: 2013-09-27 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/29bdcf12457c 8014447: Object.hashCode intrinsic breaks inline caches Summary: Try to inline as normal method first, then fall back to intrinsic. Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp Changeset: d8d059e90ec1 Author: twisti Date: 2013-09-30 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d8d059e90ec1 8025599: Missing store barrier with OptimizeStringConcat Reviewed-by: kvn, twisti Contributed-by: Axel Siebenborn ! src/share/vm/opto/graphKit.cpp Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java + test/compiler/jsr292/methodHandleExceptions/C.java + test/compiler/jsr292/methodHandleExceptions/I.java + test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - 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: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/100614790c1e Merge Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags From alejandro.murillo at oracle.com Fri Oct 4 20:47:55 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 05 Oct 2013 03:47:55 +0000 Subject: hg: hsx/jdk7u/hotspot: 8025860: new hotspot build - hs24.60-b02 Message-ID: <20131005034806.6CDB862DAE@hg.openjdk.java.net> Changeset: cba2cb15dc55 Author: amurillo Date: 2013-10-04 06:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/cba2cb15dc55 8025860: new hotspot build - hs24.60-b02 Reviewed-by: jcoomes ! make/hotspot_version From alejandro.murillo at oracle.com Sat Oct 5 00:08:04 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 05 Oct 2013 07:08:04 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131005070816.E765A62DB3@hg.openjdk.java.net> Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version From volker.simonis at gmail.com Mon Oct 7 01:59:38 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Oct 2013 10:59:38 +0200 Subject: JDK7u, hotspot, CC_INTERP, and COBOL In-Reply-To: <524F0AF0.5050007@orange.fr> References: <524322D3.4050000@orange.fr> <524F0AF0.5050007@orange.fr> Message-ID: What are your settings for 'EnableInvokeDynamic'? If you use the default which is EnableInvokeDynamic=true then verifier_max_stack() doesn't account for extra_stack_entries() and this is wrong because 'istate->_stack_limit' does (see the comment in our code). Your solution probably only seems to work because 'istate->_stack_limit' on x86 currently does not account for extra_stack_entries() which is wrong (you probalby won't be able to run any JSR292 code). I think you'll have to add something similar like // max_stack = method->max_stack(); // TODO: PPC port: assert(2 == methodOopDesc::sz_max_stack(), "unexpected field size"); __ ppc_lhz(max_stack, method_(max_stack)); if (EnableInvokeDynamic) { // Take into account 'extra_stack_entries' needed by method handles (see method.hpp) __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries()); } to CppInterpreterGenerator::generate_compute_interpreter_state() on x86 to make JSR292 work with the CPP interpreter on that platform. After you did that, you will probably see that the assertion will not work anymore with verifier_max_stack() and you'll have to use max_stack() as we did. The two different versions of the assertion in our code are only necessary, if you use a HotSpot 24 with a pre HS24 class library, in which case EnableInvokeDynamic will be switched off after CppInterpreterGenerator::generate_compute_interpreter_state was called. Regards, Volker On Fri, Oct 4, 2013 at 8:37 PM, Francis ANDRE wrote: > Hi Volker > > I had a look to the CPP-Interpreter you mention in your answer and found out > a somewhat different implementation for verifying the stack size. > > here the snippet from the ppc-aix-potr/jdk7u > #ifdef ASSERT > if (istate->_msg != initialize) { > // We have a problem here if we are running with a pre-hsx24 JDK (for > example during bootstrap) > // because in that case, EnableInvokeDynamic is true by default but will > be later switched off > // if java_lang_invoke_MethodHandle::compute_offsets() detects that the > JDK only has the classes > // for the old JSR292 implementation. > // This leads to a situation where 'istate->_stack_limit' always > accounts for > // methodOopDesc::extra_stack_entries() because it is computed in > // CppInterpreterGenerator::generate_compute_interpreter_state() which > was generated while > // EnableInvokeDynamic was still true. On the other hand, > istate->_method->max_stack() doesn't > // account for extra_stack_entries() anymore because at the time when it > is called > // EnableInvokeDynamic was already set to false. > // So we have a second version of the assertion which handles the case > where EnableInvokeDynamic was > // switched off because of the wrong classes. > if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) { > assert(labs(istate->_stack_base - istate->_stack_limit) == > (istate->_method->max_stack() + 1), "bad stack limit"); > } > else { > const int extra_stack_entries = 2; // MUST match the value in > methodOopDesc::extra_stack_entries() > assert(labs(istate->_stack_base - istate->_stack_limit) == > (istate->_method->max_stack() + extra_stack_entries > + 1), "bad stack limit"); > } > > > On my x86 build, I used this and it seems to work fine also > #ifdef ASSERT > if (istate->_msg != initialize) { > assert(abs(istate->_stack_base - istate->_stack_limit) == > (istate->_method->verifier_max_stack() + 1), "bad stack limit"); > #ifndef SHARK > IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp() > + 1, "wrong")); > #endif // !SHARK > } > > so I am wondering if it is ok to use the verifier_max_stack() function which > seems lighter from the lisibility perspective? > > > > Francis > > Le 30/09/2013 17:37, Volker Simonis a ?crit : >> >> 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 volker.simonis at gmail.com Mon Oct 7 02:17:22 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Oct 2013 11:17:22 +0200 Subject: CFV: new hsx committer: David Chase In-Reply-To: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> References: <524E5070-EE66-413A-A8C0-C925A1D7C06A@oracle.com> Message-ID: Vote: yes On Wed, Oct 2, 2013 at 8:37 AM, John Rose wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. > > Since November of 2012, David has contributed widely to the HotSpot code base. > > Here are his commits, more recent first: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=drchase > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/log?rev=david.r.chase > > 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation > 8017578: Hotspot compilation error with latest Studio compiler > 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 > 8002160: Compilation issue with adlc using latest SunStudio compilers > 8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit > 6443505: Ideal() function for CmpLTMask > 7104565: trim jprt build targets > 8007776: Test6852078.java timeouts > 7102300: performance warnings cause results diff failure in Test6890943 > 8008180: Several tests in compiler/5091921 need more time to run > 8007402: Code cleanup to remove Parfait false positive > 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray > 8006500: compiler/8004741/Test8004741.java fails intermediately > 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases > 8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > 8010913: compiler/6863420 often exceeds timeout > 8005821: C2: -XX:+PrintIntrinsics is broken > 8006204: please JTREGify test/compiler/7190310/Test7190310.java > 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum > > About four credit him (as david.r.chase) in a "Contributed-by" line; the others are under his username. > > The gross volume of contributions is 9100 lines of patch, comprising 1500 lines deleted and 2900 added, touching about 150 files. > > The change sets for 8014013, 7088419, and 6443505 are especially complex and subtle, while 7104565 is a large change to the makefile system. > > David's experience includes optimizing compilers, JVM implementations, and parallel systems, at Oracle Labs, Sun, NaturalBridge, and Thinking Machines. > > Votes are due by Tuesday, October 15. > > Only current hsx Committers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > ? John Rose > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From goetz.lindenmaier at sap.com Mon Oct 7 02:54:20 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Oct 2013 09:54:20 +0000 Subject: opto: How to use MachConstantBase with Call nodes -- needed for ppc port Message-ID: <4295855A5C1DE049A61835A1887419CC0D039EEA@DEWDFEMB12A.global.corp.sap> Hi, This is part of the ppc port, but I would like some advice before I open a bug and prepare a webrev. The next change I would like to prepare will be based on this patch: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0114_opto-hook_to_postprocess_matcher_output_platform_dependent.patch The method introduced there is later filled with code on ppc: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/compile_ppc.cpp This introduces a walk over the IR after matching, before gcm. In that walk we add MachConstantBaseNode to the call nodes (CallDynamicJava, CallLeaf and CallLeafNoFP). There are two problems why we need this: - The functionality to automatically generate an input of MachConstantBaseNode only works with subclasses of MachConstantNode. - Call nodes can not have ordinary operands with ins. We decided to implement this additional walk over the IR because it was the solution with the least change to shared code. Actually I would prefer a solution that gets along without this walk. This would be possible by adding support for ordinary ins/operands in Call nodes. The ins could be: [[The 5 basic operands] [the params] [new: the ordinary ins as specified by operands] [the jvms ins] [oop_map ins]] oper_input_base() would have to return something like 'TypeFunc::Parms + tf()->_domain->_cnt', and we would have to add oper_input_end() which does a loop over the opers and counts the ins required: oper_input_end() { int end = oper_input_base() for (uint i = 1; i < num_opnds(); ++i) { end += _opnds[i]->num_edges(); } return end; } Also, jvms->locoff() etc would have to depend on oper_input_end() in some way. Alternatively, one could put the ordinary ins behind jvms, then oper_input_base() would have to return jvms->endoff(), and oop_maps would have to use oper_input_end() to locate their first in. Further, I would have to add a new MachOperand that represents the ConstantBase What do you think? Would you rather prefer the existing solution, or should I try to implement what I described? Do you have a better idea how to add the ConstantBase to Calls? Best regards, Goetz. From roland.westrelin at oracle.com Mon Oct 7 03:41:23 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 7 Oct 2013 12:41:23 +0200 Subject: Result: New hotspot Group Member: Niclas Adlertz Message-ID: <61C143B2-B6CE-4531-AC86-0069D4BC02A2@oracle.com> The vote for Niclas Adlertz [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Roland Westrelin [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-September/010993.html From mikael.gerdin at oracle.com Mon Oct 7 05:25:18 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 07 Oct 2013 14:25:18 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> Message-ID: <5252A82E.2020107@oracle.com> Vitaly, On 10/04/2013 03:32 PM, Vitaly Davidovich wrote: > Mikael, > > What if you were to read the card value before the store and then check > if it's clean and mark it dirty + enqueue? This would be a loadstore > fence which can be noop in some archs. Or am I missing something? The problem is that we need to make sure that the refinement thread finds our reference when it cleans our card. In order to determine that we need to read the card value from memory _after_ our store to the java object is known to be visible. That way we know that the refinement has not started scanning the card and therefore won't miss our reference. If we read the card value before the store, found that it was already dirty and skipped enqueuing then we are enlarging the window for when the refinement thread may start scanning the card and scan past the address where we would store to the java object. /Mikael > > Thanks > > Sent from my phone > > On Oct 4, 2013 8:18 AM, "Mikael Gerdin" > wrote: > > David, > > On 10/04/2013 11:15 AM, David Holmes wrote: > > Hi Mikael, > > src/cpu/sparc/vm/c1_Runtime1___sparc.cpp: > > I don't quite follow the logic for this: > > __ set(rs, cardtable); // cardtable := table base> > __ ldub(addr, cardtable, tmp); // tmp := [addr + > cardtable] > > + __ cmp_and_br_short(tmp, > G1SATBCardTableModRefBS::g1___young_card_val(), Assembler::equal, > Assembler::pt, young_card); > + > + __ > membar(Assembler::Membar_mask___bits(Assembler::StoreLoad)); > + __ ldub(addr, cardtable, tmp); // tmp := [addr + > cardtable] > > You load the cardtable with no barrier, checks its value and if > it seems > "wrong" (?) you then issue the storeload barrier and try again. > Why not > just insert the storeload barrier between the store and the load? > > Similar comment for src/cpu/sparc/vm/__macroAssembler_sparc.cpp. > > --- > > src/share/vm/gc___implementation/g1/__g1SATBCardTableModRefBS.cpp: > > void > G1SATBCardTableLoggingModRefBS__::write_ref_field_work(void* > field, > oop > new_val) { > ! volatile jbyte* byte = byte_for(field); > ! if (*byte == g1_young_gen) { > ! return; > ! } > ! OrderAccess::storeload(); > > where is the store that you are ordering with? > > Similarly: > > ! for (; byte <= last_byte; byte++) { > ! if (*byte == g1_young_gen) { > ! continue; > ! } > ! OrderAccess::storeload(); > if (*byte != dirty_card) { > *byte = dirty_card; > jt->dirty_card_queue().__enqueue(byte); > } > } > > the store seems to be after the barrier ? > > > > Let me take one step back and describe the situation more thouroghly. > The post-barrier for G1 has the following structure before my change > (o is a java object, f is a field in o and x is another java object) > > o.f = x > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > The memory ordering problem can occur between the store > o.f = x and the read of *card_for(o) > This is because the concurrent refinement thread will set a card to > "clean" before it starts scanning the card for references, but that > store is not guaranteed to be visible to the thread executing the > post-barrier. > So if the CPU re-orders the load from card_for(o) to before the > write of o.f the refinement thread may have scanned past the address > of o.f but the application thread sees the stale "dirty" value and > skips the barrier. > > > The simple fix for this race is then to insert a storeload between > the store and the load: > o.f = x > #StoreLoad > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > Inserting the storeload is too expensive since this code is in the > object field write fast-path. So I introduced a way to exclude some > writes by relying on a new card value which I know is not suspect to > concurrent updates: > > o.f = x > if (*card_for(o) == g1_young) then goto done > #StoreLoad (because I can only rely on the value "dirty" if the > store was committed before the following read) > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > I hope this clarifies the issue and the reasoning behind my changes. > > /Mikael > > > Cheers, > David > > On 2/10/2013 10:28 PM, Mikael Gerdin wrote: > > Hi > > Please review my fix for the issue discussed in the "G1 > question: > concurrent cleaning of dirty cards" thread on the > hotspot-gc-dev mailing > list. > > I'd like someone from the compiler (and runtime? the > interpreter uses > macroAssembler_*, right?) teams to at least look at the > changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may > miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old > card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set > the card to > "clean" and proceeded to scan the card but the java thread > may have seen > the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and > the reading > of the previous card value. > * Modify the code for handling young regions so that all > writes to young > regions can skip the fence (since it will never be needed > for such > writes). This introduces a new value in the card table for > G1 which > indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of > 1-1.5% > (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by > redesigning G1's post barrier but there is not enough time > to do that > for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~__mgerdin/8014555/perf.txt > > > Unfortunately the JIRA issue is not externally visible, but > the major > parts of the discussions about this are present in the > mailing list > thread. The bug mostly contains my analysis of the crashes > which seems > to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/__browse/JDK-8014555 > > > Webrev: > http://cr.openjdk.java.net/~__mgerdin/8014555/webrev.0 > > > From mikael.gerdin at oracle.com Mon Oct 7 05:29:29 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 07 Oct 2013 14:29:29 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <524C1186.5070105@oracle.com> References: <524C1186.5070105@oracle.com> Message-ID: <5252A929.8080902@oracle.com> All, I plan to push this change with the additional comment as suggested by Roland. Thanks for all the reviews. /Mikael On 10/02/2013 02:28 PM, Mikael Gerdin wrote: > Hi > > Please review my fix for the issue discussed in the "G1 question: > concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing > list. > > I'd like someone from the compiler (and runtime? the interpreter uses > macroAssembler_*, right?) teams to at least look at the changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set the card to > "clean" and proceeded to scan the card but the java thread may have seen > the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and the reading > of the previous card value. > * Modify the code for handling young regions so that all writes to young > regions can skip the fence (since it will never be needed for such > writes). This introduces a new value in the card table for G1 which > indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of 1-1.5% > (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by > redesigning G1's post barrier but there is not enough time to do that > for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt > > Unfortunately the JIRA issue is not externally visible, but the major > parts of the discussions about this are present in the mailing list > thread. The bug mostly contains my analysis of the crashes which seems > to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 > From martin.doerr at sap.com Mon Oct 7 07:13:52 2013 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Oct 2013 14:13:52 +0000 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <5252A82E.2020107@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> <5252A82E.2020107@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566AC750A9@DEWDFEMB19C.global.corp.sap> Hi Mikael, your proposed webrev looks good. It does prevent the problem which I had reported. And I like the card table based recognition of young regions. I have only one comment on the new implementation of G1SATBCardTableLoggingModRefBS::invalidate. It's not necessary to execute the store-load-barrier inside the loops. E.g. it could be implemented this way: // Skip young gen. while ((byte <= last_byte) && (*byte == g1_young_gen)) byte++; if (byte <= last_byte) { // Old gen is included. Must fence before checking cards. OrderAccess::storeload(); for (; byte <= last_byte; byte++) { if (*byte == g1_young_gen) { continue; } if (*byte != dirty_card) { *byte = dirty_card; jt->dirty_card_queue().enqueue(byte); } } } (I guess the MutexLockerEx already contains some kind of store-load-ordering, but I'd keep the additional OrderAccess::storeload() in the non-java-thread case to be on the safe side.) It's probably not a big deal. Just wanted to share this thought. @Vitaly: The original problem was discussed in the thread "G1 question: concurrent cleaning of dirty cards". I had posted the following scenario: Java Thread (mutator) Refinement Thread (G1RemSet::concurrentRefineOneCard_impl calls oops_on_card_seq_iterate_careful) (1) store(oop) ( StoreLoad required here ?) (2) load(card==dirty) (1') store(card==clean) (2') StoreLoad barrier (3') load(oop) Best regards, Martin -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Mikael Gerdin Sent: Montag, 7. Oktober 2013 14:25 To: Vitaly Davidovich Cc: David Holmes; hotspot-dev developers Subject: Re: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking Vitaly, On 10/04/2013 03:32 PM, Vitaly Davidovich wrote: > Mikael, > > What if you were to read the card value before the store and then check > if it's clean and mark it dirty + enqueue? This would be a loadstore > fence which can be noop in some archs. Or am I missing something? The problem is that we need to make sure that the refinement thread finds our reference when it cleans our card. In order to determine that we need to read the card value from memory _after_ our store to the java object is known to be visible. That way we know that the refinement has not started scanning the card and therefore won't miss our reference. If we read the card value before the store, found that it was already dirty and skipped enqueuing then we are enlarging the window for when the refinement thread may start scanning the card and scan past the address where we would store to the java object. /Mikael > > Thanks > > Sent from my phone > > On Oct 4, 2013 8:18 AM, "Mikael Gerdin" > wrote: > > David, > > On 10/04/2013 11:15 AM, David Holmes wrote: > > Hi Mikael, > > src/cpu/sparc/vm/c1_Runtime1___sparc.cpp: > > I don't quite follow the logic for this: > > __ set(rs, cardtable); // cardtable := table base> > __ ldub(addr, cardtable, tmp); // tmp := [addr + > cardtable] > > + __ cmp_and_br_short(tmp, > G1SATBCardTableModRefBS::g1___young_card_val(), Assembler::equal, > Assembler::pt, young_card); > + > + __ > membar(Assembler::Membar_mask___bits(Assembler::StoreLoad)); > + __ ldub(addr, cardtable, tmp); // tmp := [addr + > cardtable] > > You load the cardtable with no barrier, checks its value and if > it seems > "wrong" (?) you then issue the storeload barrier and try again. > Why not > just insert the storeload barrier between the store and the load? > > Similar comment for src/cpu/sparc/vm/__macroAssembler_sparc.cpp. > > --- > > src/share/vm/gc___implementation/g1/__g1SATBCardTableModRefBS.cpp: > > void > G1SATBCardTableLoggingModRefBS__::write_ref_field_work(void* > field, > oop > new_val) { > ! volatile jbyte* byte = byte_for(field); > ! if (*byte == g1_young_gen) { > ! return; > ! } > ! OrderAccess::storeload(); > > where is the store that you are ordering with? > > Similarly: > > ! for (; byte <= last_byte; byte++) { > ! if (*byte == g1_young_gen) { > ! continue; > ! } > ! OrderAccess::storeload(); > if (*byte != dirty_card) { > *byte = dirty_card; > jt->dirty_card_queue().__enqueue(byte); > } > } > > the store seems to be after the barrier ? > > > > Let me take one step back and describe the situation more thouroghly. > The post-barrier for G1 has the following structure before my change > (o is a java object, f is a field in o and x is another java object) > > o.f = x > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > The memory ordering problem can occur between the store > o.f = x and the read of *card_for(o) > This is because the concurrent refinement thread will set a card to > "clean" before it starts scanning the card for references, but that > store is not guaranteed to be visible to the thread executing the > post-barrier. > So if the CPU re-orders the load from card_for(o) to before the > write of o.f the refinement thread may have scanned past the address > of o.f but the application thread sees the stale "dirty" value and > skips the barrier. > > > The simple fix for this race is then to insert a storeload between > the store and the load: > o.f = x > #StoreLoad > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > Inserting the storeload is too expensive since this code is in the > object field write fast-path. So I introduced a way to exclude some > writes by relying on a new card value which I know is not suspect to > concurrent updates: > > o.f = x > if (*card_for(o) == g1_young) then goto done > #StoreLoad (because I can only rely on the value "dirty" if the > store was committed before the following read) > if (*card_for(o) == dirty) then goto done > *card_for(o) = dirty > enqueue(card_for(o)) > done: > > I hope this clarifies the issue and the reasoning behind my changes. > > /Mikael > > > Cheers, > David > > On 2/10/2013 10:28 PM, Mikael Gerdin wrote: > > Hi > > Please review my fix for the issue discussed in the "G1 > question: > concurrent cleaning of dirty cards" thread on the > hotspot-gc-dev mailing > list. > > I'd like someone from the compiler (and runtime? the > interpreter uses > macroAssembler_*, right?) teams to at least look at the > changes to: > macroAssembler_*.cpp > c1_Runtime_*.cpp > graphKit.cpp > > Problem description: > G1 has a race where the concurrent refinement thread may > miss object > references in a dirty card. > The problem arises if the CPU re-orders the load of the old > card value > (which G1 checks to determine if it can skip the barrier) > before the store to the actual object. > If that occurs the concurrent refinement thread may have set > the card to > "clean" and proceeded to scan the card but the java thread > may have seen > the "dirty" value and skipped the post barrier. > > Suggested fix: > * Add a memory fence between the store to a java object and > the reading > of the previous card value. > * Modify the code for handling young regions so that all > writes to young > regions can skip the fence (since it will never be needed > for such > writes). This introduces a new value in the card table for > G1 which > indicates a young region. > > Performance impact: > * This fix has a negative throughput performance impact of > 1-1.5% > (tested on x86-AMD x86-Intel and SPARC). > * We may want to try to get rid of this race at some point by > redesigning G1's post barrier but there is not enough time > to do that > for JDK8. > > Performance numbers for x86 platforms can be seen here: > http://cr.openjdk.java.net/~__mgerdin/8014555/perf.txt > > > Unfortunately the JIRA issue is not externally visible, but > the major > parts of the discussions about this are present in the > mailing list > thread. The bug mostly contains my analysis of the crashes > which seems > to have been caused by this bug. > > Bug link: https://bugs.openjdk.java.net/__browse/JDK-8014555 > > > Webrev: > http://cr.openjdk.java.net/~__mgerdin/8014555/webrev.0 > > > From mikael.gerdin at oracle.com Mon Oct 7 08:49:02 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 07 Oct 2013 17:49:02 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116566AC750A9@DEWDFEMB19C.global.corp.sap> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> <5252A82E.2020107@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566AC750A9@DEWDFEMB19C.global.corp.sap> Message-ID: <5252D7EE.2000305@oracle.com> Hi Martin, On 10/07/2013 04:13 PM, Doerr, Martin wrote: > Hi Mikael, > > your proposed webrev looks good. It does prevent the problem which I had reported. > And I like the card table based recognition of young regions. > > I have only one comment on the new implementation of G1SATBCardTableLoggingModRefBS::invalidate. > It's not necessary to execute the store-load-barrier inside the loops. E.g. it could be implemented this way: > // Skip young gen. > while ((byte <= last_byte) && (*byte == g1_young_gen)) byte++; > if (byte <= last_byte) { > // Old gen is included. Must fence before checking cards. > OrderAccess::storeload(); > for (; byte <= last_byte; byte++) { > if (*byte == g1_young_gen) { > continue; > } > if (*byte != dirty_card) { > *byte = dirty_card; > jt->dirty_card_queue().enqueue(byte); > } > } > } Ahh, you are correct. I like your idea but I modified it slightly. Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0.to.1/ Full webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.1/ /Mikael > > (I guess the MutexLockerEx already contains some kind of store-load-ordering, but I'd keep the additional > OrderAccess::storeload() in the non-java-thread case to be on the safe side.) > It's probably not a big deal. Just wanted to share this thought. You are probably correct, but I'd like to keep the code consistent and I dont think calling invalidate() from the VM thread is a hot path. /Mikael > > @Vitaly: The original problem was discussed in the thread "G1 question: concurrent cleaning of dirty cards". > I had posted the following scenario: > Java Thread (mutator) Refinement Thread (G1RemSet::concurrentRefineOneCard_impl calls oops_on_card_seq_iterate_careful) > > (1) store(oop) > ( StoreLoad required here ?) > (2) load(card==dirty) > > (1') store(card==clean) > (2') StoreLoad barrier > (3') load(oop) > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Mikael Gerdin > Sent: Montag, 7. Oktober 2013 14:25 > To: Vitaly Davidovich > Cc: David Holmes; hotspot-dev developers > Subject: Re: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking > > Vitaly, > > On 10/04/2013 03:32 PM, Vitaly Davidovich wrote: >> Mikael, >> >> What if you were to read the card value before the store and then check >> if it's clean and mark it dirty + enqueue? This would be a loadstore >> fence which can be noop in some archs. Or am I missing something? > > The problem is that we need to make sure that the refinement thread > finds our reference when it cleans our card. > In order to determine that we need to read the card value from memory > _after_ our store to the java object is known to be visible. > That way we know that the refinement has not started scanning the card > and therefore won't miss our reference. > > If we read the card value before the store, found that it was already > dirty and skipped enqueuing then we are enlarging the window for when > the refinement thread may start scanning the card and scan past the > address where we would store to the java object. > > /Mikael > >> >> Thanks >> >> Sent from my phone >> >> On Oct 4, 2013 8:18 AM, "Mikael Gerdin" > > wrote: >> >> David, >> >> On 10/04/2013 11:15 AM, David Holmes wrote: >> >> Hi Mikael, >> >> src/cpu/sparc/vm/c1_Runtime1___sparc.cpp: >> >> I don't quite follow the logic for this: >> >> __ set(rs, cardtable); // cardtable := > table base> >> __ ldub(addr, cardtable, tmp); // tmp := [addr + >> cardtable] >> >> + __ cmp_and_br_short(tmp, >> G1SATBCardTableModRefBS::g1___young_card_val(), Assembler::equal, >> Assembler::pt, young_card); >> + >> + __ >> membar(Assembler::Membar_mask___bits(Assembler::StoreLoad)); >> + __ ldub(addr, cardtable, tmp); // tmp := [addr + >> cardtable] >> >> You load the cardtable with no barrier, checks its value and if >> it seems >> "wrong" (?) you then issue the storeload barrier and try again. >> Why not >> just insert the storeload barrier between the store and the load? >> >> Similar comment for src/cpu/sparc/vm/__macroAssembler_sparc.cpp. >> >> --- >> >> src/share/vm/gc___implementation/g1/__g1SATBCardTableModRefBS.cpp: >> >> void >> G1SATBCardTableLoggingModRefBS__::write_ref_field_work(void* >> field, >> oop >> new_val) { >> ! volatile jbyte* byte = byte_for(field); >> ! if (*byte == g1_young_gen) { >> ! return; >> ! } >> ! OrderAccess::storeload(); >> >> where is the store that you are ordering with? >> >> Similarly: >> >> ! for (; byte <= last_byte; byte++) { >> ! if (*byte == g1_young_gen) { >> ! continue; >> ! } >> ! OrderAccess::storeload(); >> if (*byte != dirty_card) { >> *byte = dirty_card; >> jt->dirty_card_queue().__enqueue(byte); >> } >> } >> >> the store seems to be after the barrier ? >> >> >> >> Let me take one step back and describe the situation more thouroghly. >> The post-barrier for G1 has the following structure before my change >> (o is a java object, f is a field in o and x is another java object) >> >> o.f = x >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> The memory ordering problem can occur between the store >> o.f = x and the read of *card_for(o) >> This is because the concurrent refinement thread will set a card to >> "clean" before it starts scanning the card for references, but that >> store is not guaranteed to be visible to the thread executing the >> post-barrier. >> So if the CPU re-orders the load from card_for(o) to before the >> write of o.f the refinement thread may have scanned past the address >> of o.f but the application thread sees the stale "dirty" value and >> skips the barrier. >> >> >> The simple fix for this race is then to insert a storeload between >> the store and the load: >> o.f = x >> #StoreLoad >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> Inserting the storeload is too expensive since this code is in the >> object field write fast-path. So I introduced a way to exclude some >> writes by relying on a new card value which I know is not suspect to >> concurrent updates: >> >> o.f = x >> if (*card_for(o) == g1_young) then goto done >> #StoreLoad (because I can only rely on the value "dirty" if the >> store was committed before the following read) >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> I hope this clarifies the issue and the reasoning behind my changes. >> >> /Mikael >> >> >> Cheers, >> David >> >> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >> >> Hi >> >> Please review my fix for the issue discussed in the "G1 >> question: >> concurrent cleaning of dirty cards" thread on the >> hotspot-gc-dev mailing >> list. >> >> I'd like someone from the compiler (and runtime? the >> interpreter uses >> macroAssembler_*, right?) teams to at least look at the >> changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may >> miss object >> references in a dirty card. >> The problem arises if the CPU re-orders the load of the old >> card value >> (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set >> the card to >> "clean" and proceeded to scan the card but the java thread >> may have seen >> the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and >> the reading >> of the previous card value. >> * Modify the code for handling young regions so that all >> writes to young >> regions can skip the fence (since it will never be needed >> for such >> writes). This introduces a new value in the card table for >> G1 which >> indicates a young region. >> >> Performance impact: >> * This fix has a negative throughput performance impact of >> 1-1.5% >> (tested on x86-AMD x86-Intel and SPARC). >> * We may want to try to get rid of this race at some point by >> redesigning G1's post barrier but there is not enough time >> to do that >> for JDK8. >> >> Performance numbers for x86 platforms can be seen here: >> http://cr.openjdk.java.net/~__mgerdin/8014555/perf.txt >> >> >> Unfortunately the JIRA issue is not externally visible, but >> the major >> parts of the discussions about this are present in the >> mailing list >> thread. The bug mostly contains my analysis of the crashes >> which seems >> to have been caused by this bug. >> >> Bug link: https://bugs.openjdk.java.net/__browse/JDK-8014555 >> >> >> Webrev: >> http://cr.openjdk.java.net/~__mgerdin/8014555/webrev.0 >> >> >> > From martin.doerr at sap.com Mon Oct 7 09:04:08 2013 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Oct 2013 16:04:08 +0000 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <5252D7EE.2000305@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> <5252A82E.2020107@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566AC750A9@DEWDFEMB19C.global.corp.sap> <5252D7EE.2000305@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566AC750F1@DEWDFEMB19C.global.corp.sap> Hi Mikael, it's even better this way. Thanks for adding my proposal so quickly, Martin -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Montag, 7. Oktober 2013 17:49 To: Doerr, Martin; Vitaly Davidovich Cc: David Holmes; hotspot-dev developers Subject: Re: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking Hi Martin, On 10/07/2013 04:13 PM, Doerr, Martin wrote: > Hi Mikael, > > your proposed webrev looks good. It does prevent the problem which I had reported. > And I like the card table based recognition of young regions. > > I have only one comment on the new implementation of G1SATBCardTableLoggingModRefBS::invalidate. > It's not necessary to execute the store-load-barrier inside the loops. E.g. it could be implemented this way: > // Skip young gen. > while ((byte <= last_byte) && (*byte == g1_young_gen)) byte++; > if (byte <= last_byte) { > // Old gen is included. Must fence before checking cards. > OrderAccess::storeload(); > for (; byte <= last_byte; byte++) { > if (*byte == g1_young_gen) { > continue; > } > if (*byte != dirty_card) { > *byte = dirty_card; > jt->dirty_card_queue().enqueue(byte); > } > } > } Ahh, you are correct. I like your idea but I modified it slightly. Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0.to.1/ Full webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.1/ /Mikael > > (I guess the MutexLockerEx already contains some kind of store-load-ordering, but I'd keep the additional > OrderAccess::storeload() in the non-java-thread case to be on the safe side.) > It's probably not a big deal. Just wanted to share this thought. You are probably correct, but I'd like to keep the code consistent and I dont think calling invalidate() from the VM thread is a hot path. /Mikael > > @Vitaly: The original problem was discussed in the thread "G1 question: concurrent cleaning of dirty cards". > I had posted the following scenario: > Java Thread (mutator) Refinement Thread (G1RemSet::concurrentRefineOneCard_impl calls oops_on_card_seq_iterate_careful) > > (1) store(oop) > ( StoreLoad required here ?) > (2) load(card==dirty) > > (1') store(card==clean) > (2') StoreLoad barrier > (3') load(oop) > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Mikael Gerdin > Sent: Montag, 7. Oktober 2013 14:25 > To: Vitaly Davidovich > Cc: David Holmes; hotspot-dev developers > Subject: Re: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking > > Vitaly, > > On 10/04/2013 03:32 PM, Vitaly Davidovich wrote: >> Mikael, >> >> What if you were to read the card value before the store and then check >> if it's clean and mark it dirty + enqueue? This would be a loadstore >> fence which can be noop in some archs. Or am I missing something? > > The problem is that we need to make sure that the refinement thread > finds our reference when it cleans our card. > In order to determine that we need to read the card value from memory > _after_ our store to the java object is known to be visible. > That way we know that the refinement has not started scanning the card > and therefore won't miss our reference. > > If we read the card value before the store, found that it was already > dirty and skipped enqueuing then we are enlarging the window for when > the refinement thread may start scanning the card and scan past the > address where we would store to the java object. > > /Mikael > >> >> Thanks >> >> Sent from my phone >> >> On Oct 4, 2013 8:18 AM, "Mikael Gerdin" > > wrote: >> >> David, >> >> On 10/04/2013 11:15 AM, David Holmes wrote: >> >> Hi Mikael, >> >> src/cpu/sparc/vm/c1_Runtime1___sparc.cpp: >> >> I don't quite follow the logic for this: >> >> __ set(rs, cardtable); // cardtable := > table base> >> __ ldub(addr, cardtable, tmp); // tmp := [addr + >> cardtable] >> >> + __ cmp_and_br_short(tmp, >> G1SATBCardTableModRefBS::g1___young_card_val(), Assembler::equal, >> Assembler::pt, young_card); >> + >> + __ >> membar(Assembler::Membar_mask___bits(Assembler::StoreLoad)); >> + __ ldub(addr, cardtable, tmp); // tmp := [addr + >> cardtable] >> >> You load the cardtable with no barrier, checks its value and if >> it seems >> "wrong" (?) you then issue the storeload barrier and try again. >> Why not >> just insert the storeload barrier between the store and the load? >> >> Similar comment for src/cpu/sparc/vm/__macroAssembler_sparc.cpp. >> >> --- >> >> src/share/vm/gc___implementation/g1/__g1SATBCardTableModRefBS.cpp: >> >> void >> G1SATBCardTableLoggingModRefBS__::write_ref_field_work(void* >> field, >> oop >> new_val) { >> ! volatile jbyte* byte = byte_for(field); >> ! if (*byte == g1_young_gen) { >> ! return; >> ! } >> ! OrderAccess::storeload(); >> >> where is the store that you are ordering with? >> >> Similarly: >> >> ! for (; byte <= last_byte; byte++) { >> ! if (*byte == g1_young_gen) { >> ! continue; >> ! } >> ! OrderAccess::storeload(); >> if (*byte != dirty_card) { >> *byte = dirty_card; >> jt->dirty_card_queue().__enqueue(byte); >> } >> } >> >> the store seems to be after the barrier ? >> >> >> >> Let me take one step back and describe the situation more thouroghly. >> The post-barrier for G1 has the following structure before my change >> (o is a java object, f is a field in o and x is another java object) >> >> o.f = x >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> The memory ordering problem can occur between the store >> o.f = x and the read of *card_for(o) >> This is because the concurrent refinement thread will set a card to >> "clean" before it starts scanning the card for references, but that >> store is not guaranteed to be visible to the thread executing the >> post-barrier. >> So if the CPU re-orders the load from card_for(o) to before the >> write of o.f the refinement thread may have scanned past the address >> of o.f but the application thread sees the stale "dirty" value and >> skips the barrier. >> >> >> The simple fix for this race is then to insert a storeload between >> the store and the load: >> o.f = x >> #StoreLoad >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> Inserting the storeload is too expensive since this code is in the >> object field write fast-path. So I introduced a way to exclude some >> writes by relying on a new card value which I know is not suspect to >> concurrent updates: >> >> o.f = x >> if (*card_for(o) == g1_young) then goto done >> #StoreLoad (because I can only rely on the value "dirty" if the >> store was committed before the following read) >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> I hope this clarifies the issue and the reasoning behind my changes. >> >> /Mikael >> >> >> Cheers, >> David >> >> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >> >> Hi >> >> Please review my fix for the issue discussed in the "G1 >> question: >> concurrent cleaning of dirty cards" thread on the >> hotspot-gc-dev mailing >> list. >> >> I'd like someone from the compiler (and runtime? the >> interpreter uses >> macroAssembler_*, right?) teams to at least look at the >> changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may >> miss object >> references in a dirty card. >> The problem arises if the CPU re-orders the load of the old >> card value >> (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set >> the card to >> "clean" and proceeded to scan the card but the java thread >> may have seen >> the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and >> the reading >> of the previous card value. >> * Modify the code for handling young regions so that all >> writes to young >> regions can skip the fence (since it will never be needed >> for such >> writes). This introduces a new value in the card table for >> G1 which >> indicates a young region. >> >> Performance impact: >> * This fix has a negative throughput performance impact of >> 1-1.5% >> (tested on x86-AMD x86-Intel and SPARC). >> * We may want to try to get rid of this race at some point by >> redesigning G1's post barrier but there is not enough time >> to do that >> for JDK8. >> >> Performance numbers for x86 platforms can be seen here: >> http://cr.openjdk.java.net/~__mgerdin/8014555/perf.txt >> >> >> Unfortunately the JIRA issue is not externally visible, but >> the major >> parts of the discussions about this are present in the >> mailing list >> thread. The bug mostly contains my analysis of the crashes >> which seems >> to have been caused by this bug. >> >> Bug link: https://bugs.openjdk.java.net/__browse/JDK-8014555 >> >> >> Webrev: >> http://cr.openjdk.java.net/~__mgerdin/8014555/webrev.0 >> >> >> > From vitalyd at gmail.com Mon Oct 7 17:08:24 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 7 Oct 2013 20:08:24 -0400 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <5252A82E.2020107@oracle.com> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> <5252A82E.2020107@oracle.com> Message-ID: Got it, thanks Mikael - sorry for the noise. Sent from my phone On Oct 7, 2013 8:25 AM, "Mikael Gerdin" wrote: > Vitaly, > > On 10/04/2013 03:32 PM, Vitaly Davidovich wrote: > >> Mikael, >> >> What if you were to read the card value before the store and then check >> if it's clean and mark it dirty + enqueue? This would be a loadstore >> fence which can be noop in some archs. Or am I missing something? >> > > The problem is that we need to make sure that the refinement thread finds > our reference when it cleans our card. > In order to determine that we need to read the card value from memory > _after_ our store to the java object is known to be visible. > That way we know that the refinement has not started scanning the card and > therefore won't miss our reference. > > If we read the card value before the store, found that it was already > dirty and skipped enqueuing then we are enlarging the window for when the > refinement thread may start scanning the card and scan past the address > where we would store to the java object. > > /Mikael > > >> Thanks >> >> Sent from my phone >> >> On Oct 4, 2013 8:18 AM, "Mikael Gerdin" > >> wrote: >> >> David, >> >> On 10/04/2013 11:15 AM, David Holmes wrote: >> >> Hi Mikael, >> >> src/cpu/sparc/vm/c1_Runtime1__**_sparc.cpp: >> >> I don't quite follow the logic for this: >> >> __ set(rs, cardtable); // cardtable := > table base> >> __ ldub(addr, cardtable, tmp); // tmp := [addr + >> cardtable] >> >> + __ cmp_and_br_short(tmp, >> G1SATBCardTableModRefBS::g1___**young_card_val(), >> Assembler::equal, >> Assembler::pt, young_card); >> + >> + __ >> membar(Assembler::Membar_mask_**__bits(Assembler::StoreLoad)); >> + __ ldub(addr, cardtable, tmp); // tmp := [addr + >> cardtable] >> >> You load the cardtable with no barrier, checks its value and if >> it seems >> "wrong" (?) you then issue the storeload barrier and try again. >> Why not >> just insert the storeload barrier between the store and the load? >> >> Similar comment for src/cpu/sparc/vm/__** >> macroAssembler_sparc.cpp. >> >> --- >> >> src/share/vm/gc___**implementation/g1/__** >> g1SATBCardTableModRefBS.cpp: >> >> void >> G1SATBCardTableLoggingModRefBS** >> __::write_ref_field_work(void* >> field, >> oop >> new_val) { >> ! volatile jbyte* byte = byte_for(field); >> ! if (*byte == g1_young_gen) { >> ! return; >> ! } >> ! OrderAccess::storeload(); >> >> where is the store that you are ordering with? >> >> Similarly: >> >> ! for (; byte <= last_byte; byte++) { >> ! if (*byte == g1_young_gen) { >> ! continue; >> ! } >> ! OrderAccess::storeload(); >> if (*byte != dirty_card) { >> *byte = dirty_card; >> jt->dirty_card_queue().__**enqueue(byte); >> } >> } >> >> the store seems to be after the barrier ? >> >> >> >> Let me take one step back and describe the situation more thouroghly. >> The post-barrier for G1 has the following structure before my change >> (o is a java object, f is a field in o and x is another java object) >> >> o.f = x >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> The memory ordering problem can occur between the store >> o.f = x and the read of *card_for(o) >> This is because the concurrent refinement thread will set a card to >> "clean" before it starts scanning the card for references, but that >> store is not guaranteed to be visible to the thread executing the >> post-barrier. >> So if the CPU re-orders the load from card_for(o) to before the >> write of o.f the refinement thread may have scanned past the address >> of o.f but the application thread sees the stale "dirty" value and >> skips the barrier. >> >> >> The simple fix for this race is then to insert a storeload between >> the store and the load: >> o.f = x >> #StoreLoad >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> Inserting the storeload is too expensive since this code is in the >> object field write fast-path. So I introduced a way to exclude some >> writes by relying on a new card value which I know is not suspect to >> concurrent updates: >> >> o.f = x >> if (*card_for(o) == g1_young) then goto done >> #StoreLoad (because I can only rely on the value "dirty" if the >> store was committed before the following read) >> if (*card_for(o) == dirty) then goto done >> *card_for(o) = dirty >> enqueue(card_for(o)) >> done: >> >> I hope this clarifies the issue and the reasoning behind my changes. >> >> /Mikael >> >> >> Cheers, >> David >> >> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >> >> Hi >> >> Please review my fix for the issue discussed in the "G1 >> question: >> concurrent cleaning of dirty cards" thread on the >> hotspot-gc-dev mailing >> list. >> >> I'd like someone from the compiler (and runtime? the >> interpreter uses >> macroAssembler_*, right?) teams to at least look at the >> changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may >> miss object >> references in a dirty card. >> The problem arises if the CPU re-orders the load of the old >> card value >> (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set >> the card to >> "clean" and proceeded to scan the card but the java thread >> may have seen >> the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and >> the reading >> of the previous card value. >> * Modify the code for handling young regions so that all >> writes to young >> regions can skip the fence (since it will never be needed >> for such >> writes). This introduces a new value in the card table for >> G1 which >> indicates a young region. >> >> Performance impact: >> * This fix has a negative throughput performance impact of >> 1-1.5% >> (tested on x86-AMD x86-Intel and SPARC). >> * We may want to try to get rid of this race at some point by >> redesigning G1's post barrier but there is not enough time >> to do that >> for JDK8. >> >> Performance numbers for x86 platforms can be seen here: >> http://cr.openjdk.java.net/~__**mgerdin/8014555/perf.txt >> >> > >> >> Unfortunately the JIRA issue is not externally visible, but >> the major >> parts of the discussions about this are present in the >> mailing list >> thread. The bug mostly contains my analysis of the crashes >> which seems >> to have been caused by this bug. >> >> Bug link: https://bugs.openjdk.java.net/** >> __browse/JDK-8014555 >> >> > >> >> Webrev: >> http://cr.openjdk.java.net/~__**mgerdin/8014555/webrev.0 >> >> > >> >> >> > From stefan.karlsson at oracle.com Mon Oct 7 23:21:31 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 08 Oct 2013 08:21:31 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Message-ID: <5253A46B.2010406@oracle.com> Please, review this patch to limit the committed Metaspace memory against the MaxMetaspaceSize flag. http://cr.openjdk.java.net/~stefank/8024547/webrev.00 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: TBD1, TBD2 To simplify the code, the patch is strict about the alignments used to commit and reserve memory in the metaspaces. The Metaspace VirtualSpaces always have addresses and sizes that are aligned against Metaspace::reserve_alignment(). The reserve alignment is os::vm_allocation_granularity() if small pages are used or os::large_page_size() if large pages are used in the Metaspace. The memory is always committed in regions that are size aligned against Metaspace::commit_alignment(). The commit alignment is os:page_size() if small pages are used or os::large_page_size() if late pages are used in the Metaspace. The user can specify the flag -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. The flag initialization was moved out of the CollectorPolicy class. The Metaspace specific flags have been changed to be commit/reserve aligned instead of using heap specific alignments. The output from PrintHeapAtGC has been changed. The redundant "data space" section has been removed. All of used, capacity, committed and reserved are printed. Example: Metaspace used 7644K, capacity 7700K, committed 7808K, reserved 1056768K class space used 804K, capacity 822K, committed 896K, reserved 1048576K Thanks go out to the engineers who have helped out with this bug: Erik, Mikael and Bengt for helping out with parts of the code and testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes and providing early feedback. thanks, StefanK From mikael.gerdin at oracle.com Tue Oct 8 01:05:23 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 08 Oct 2013 10:05:23 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116566AC750F1@DEWDFEMB19C.global.corp.sap> References: <524C1186.5070105@oracle.com> <524E8718.1080009@oracle.com> <524EB1E6.5070001@oracle.com> <5252A82E.2020107@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566AC750A9@DEWDFEMB19C.global.corp.sap> <5252D7EE.2000305@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566AC750F1@DEWDFEMB19C.global.corp.sap> Message-ID: <5253BCC3.9010005@oracle.com> Martin, On 10/07/2013 06:04 PM, Doerr, Martin wrote: > Hi Mikael, > > it's even better this way. Thanks for reviewing! /Mikael > > Thanks for adding my proposal so quickly, > Martin > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Montag, 7. Oktober 2013 17:49 > To: Doerr, Martin; Vitaly Davidovich > Cc: David Holmes; hotspot-dev developers > Subject: Re: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking > > Hi Martin, > > On 10/07/2013 04:13 PM, Doerr, Martin wrote: >> Hi Mikael, >> >> your proposed webrev looks good. It does prevent the problem which I had reported. >> And I like the card table based recognition of young regions. >> >> I have only one comment on the new implementation of G1SATBCardTableLoggingModRefBS::invalidate. >> It's not necessary to execute the store-load-barrier inside the loops. E.g. it could be implemented this way: >> // Skip young gen. >> while ((byte <= last_byte) && (*byte == g1_young_gen)) byte++; >> if (byte <= last_byte) { >> // Old gen is included. Must fence before checking cards. >> OrderAccess::storeload(); >> for (; byte <= last_byte; byte++) { >> if (*byte == g1_young_gen) { >> continue; >> } >> if (*byte != dirty_card) { >> *byte = dirty_card; >> jt->dirty_card_queue().enqueue(byte); >> } >> } >> } > > Ahh, you are correct. I like your idea but I modified it slightly. > > Incremental webrev: > http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0.to.1/ > Full webrev: > http://cr.openjdk.java.net/~mgerdin/8014555/webrev.1/ > > /Mikael > >> >> (I guess the MutexLockerEx already contains some kind of store-load-ordering, but I'd keep the additional >> OrderAccess::storeload() in the non-java-thread case to be on the safe side.) >> It's probably not a big deal. Just wanted to share this thought. > > You are probably correct, but I'd like to keep the code consistent and I > dont think calling invalidate() from the VM thread is a hot path. > > /Mikael > >> >> @Vitaly: The original problem was discussed in the thread "G1 question: concurrent cleaning of dirty cards". >> I had posted the following scenario: >> Java Thread (mutator) Refinement Thread (G1RemSet::concurrentRefineOneCard_impl calls oops_on_card_seq_iterate_careful) >> >> (1) store(oop) >> ( StoreLoad required here ?) >> (2) load(card==dirty) >> >> (1') store(card==clean) >> (2') StoreLoad barrier >> (3') load(oop) >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Mikael Gerdin >> Sent: Montag, 7. Oktober 2013 14:25 >> To: Vitaly Davidovich >> Cc: David Holmes; hotspot-dev developers >> Subject: Re: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking >> >> Vitaly, >> >> On 10/04/2013 03:32 PM, Vitaly Davidovich wrote: >>> Mikael, >>> >>> What if you were to read the card value before the store and then check >>> if it's clean and mark it dirty + enqueue? This would be a loadstore >>> fence which can be noop in some archs. Or am I missing something? >> >> The problem is that we need to make sure that the refinement thread >> finds our reference when it cleans our card. >> In order to determine that we need to read the card value from memory >> _after_ our store to the java object is known to be visible. >> That way we know that the refinement has not started scanning the card >> and therefore won't miss our reference. >> >> If we read the card value before the store, found that it was already >> dirty and skipped enqueuing then we are enlarging the window for when >> the refinement thread may start scanning the card and scan past the >> address where we would store to the java object. >> >> /Mikael >> >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Oct 4, 2013 8:18 AM, "Mikael Gerdin" >> > wrote: >>> >>> David, >>> >>> On 10/04/2013 11:15 AM, David Holmes wrote: >>> >>> Hi Mikael, >>> >>> src/cpu/sparc/vm/c1_Runtime1___sparc.cpp: >>> >>> I don't quite follow the logic for this: >>> >>> __ set(rs, cardtable); // cardtable := >> table base> >>> __ ldub(addr, cardtable, tmp); // tmp := [addr + >>> cardtable] >>> >>> + __ cmp_and_br_short(tmp, >>> G1SATBCardTableModRefBS::g1___young_card_val(), Assembler::equal, >>> Assembler::pt, young_card); >>> + >>> + __ >>> membar(Assembler::Membar_mask___bits(Assembler::StoreLoad)); >>> + __ ldub(addr, cardtable, tmp); // tmp := [addr + >>> cardtable] >>> >>> You load the cardtable with no barrier, checks its value and if >>> it seems >>> "wrong" (?) you then issue the storeload barrier and try again. >>> Why not >>> just insert the storeload barrier between the store and the load? >>> >>> Similar comment for src/cpu/sparc/vm/__macroAssembler_sparc.cpp. >>> >>> --- >>> >>> src/share/vm/gc___implementation/g1/__g1SATBCardTableModRefBS.cpp: >>> >>> void >>> G1SATBCardTableLoggingModRefBS__::write_ref_field_work(void* >>> field, >>> oop >>> new_val) { >>> ! volatile jbyte* byte = byte_for(field); >>> ! if (*byte == g1_young_gen) { >>> ! return; >>> ! } >>> ! OrderAccess::storeload(); >>> >>> where is the store that you are ordering with? >>> >>> Similarly: >>> >>> ! for (; byte <= last_byte; byte++) { >>> ! if (*byte == g1_young_gen) { >>> ! continue; >>> ! } >>> ! OrderAccess::storeload(); >>> if (*byte != dirty_card) { >>> *byte = dirty_card; >>> jt->dirty_card_queue().__enqueue(byte); >>> } >>> } >>> >>> the store seems to be after the barrier ? >>> >>> >>> >>> Let me take one step back and describe the situation more thouroghly. >>> The post-barrier for G1 has the following structure before my change >>> (o is a java object, f is a field in o and x is another java object) >>> >>> o.f = x >>> if (*card_for(o) == dirty) then goto done >>> *card_for(o) = dirty >>> enqueue(card_for(o)) >>> done: >>> >>> The memory ordering problem can occur between the store >>> o.f = x and the read of *card_for(o) >>> This is because the concurrent refinement thread will set a card to >>> "clean" before it starts scanning the card for references, but that >>> store is not guaranteed to be visible to the thread executing the >>> post-barrier. >>> So if the CPU re-orders the load from card_for(o) to before the >>> write of o.f the refinement thread may have scanned past the address >>> of o.f but the application thread sees the stale "dirty" value and >>> skips the barrier. >>> >>> >>> The simple fix for this race is then to insert a storeload between >>> the store and the load: >>> o.f = x >>> #StoreLoad >>> if (*card_for(o) == dirty) then goto done >>> *card_for(o) = dirty >>> enqueue(card_for(o)) >>> done: >>> >>> Inserting the storeload is too expensive since this code is in the >>> object field write fast-path. So I introduced a way to exclude some >>> writes by relying on a new card value which I know is not suspect to >>> concurrent updates: >>> >>> o.f = x >>> if (*card_for(o) == g1_young) then goto done >>> #StoreLoad (because I can only rely on the value "dirty" if the >>> store was committed before the following read) >>> if (*card_for(o) == dirty) then goto done >>> *card_for(o) = dirty >>> enqueue(card_for(o)) >>> done: >>> >>> I hope this clarifies the issue and the reasoning behind my changes. >>> >>> /Mikael >>> >>> >>> Cheers, >>> David >>> >>> On 2/10/2013 10:28 PM, Mikael Gerdin wrote: >>> >>> Hi >>> >>> Please review my fix for the issue discussed in the "G1 >>> question: >>> concurrent cleaning of dirty cards" thread on the >>> hotspot-gc-dev mailing >>> list. >>> >>> I'd like someone from the compiler (and runtime? the >>> interpreter uses >>> macroAssembler_*, right?) teams to at least look at the >>> changes to: >>> macroAssembler_*.cpp >>> c1_Runtime_*.cpp >>> graphKit.cpp >>> >>> Problem description: >>> G1 has a race where the concurrent refinement thread may >>> miss object >>> references in a dirty card. >>> The problem arises if the CPU re-orders the load of the old >>> card value >>> (which G1 checks to determine if it can skip the barrier) >>> before the store to the actual object. >>> If that occurs the concurrent refinement thread may have set >>> the card to >>> "clean" and proceeded to scan the card but the java thread >>> may have seen >>> the "dirty" value and skipped the post barrier. >>> >>> Suggested fix: >>> * Add a memory fence between the store to a java object and >>> the reading >>> of the previous card value. >>> * Modify the code for handling young regions so that all >>> writes to young >>> regions can skip the fence (since it will never be needed >>> for such >>> writes). This introduces a new value in the card table for >>> G1 which >>> indicates a young region. >>> >>> Performance impact: >>> * This fix has a negative throughput performance impact of >>> 1-1.5% >>> (tested on x86-AMD x86-Intel and SPARC). >>> * We may want to try to get rid of this race at some point by >>> redesigning G1's post barrier but there is not enough time >>> to do that >>> for JDK8. >>> >>> Performance numbers for x86 platforms can be seen here: >>> http://cr.openjdk.java.net/~__mgerdin/8014555/perf.txt >>> >>> >>> Unfortunately the JIRA issue is not externally visible, but >>> the major >>> parts of the discussions about this are present in the >>> mailing list >>> thread. The bug mostly contains my analysis of the crashes >>> which seems >>> to have been caused by this bug. >>> >>> Bug link: https://bugs.openjdk.java.net/__browse/JDK-8014555 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~__mgerdin/8014555/webrev.0 >>> >>> >>> >> > From mikael.gerdin at oracle.com Tue Oct 8 01:11:50 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 08 Oct 2013 10:11:50 +0200 Subject: RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking In-Reply-To: <5252A929.8080902@oracle.com> References: <524C1186.5070105@oracle.com> <5252A929.8080902@oracle.com> Message-ID: <5253BE46.2080603@oracle.com> Hi, On 10/07/2013 02:29 PM, Mikael Gerdin wrote: > All, > > I plan to push this change with the additional comment as suggested by > Roland. Thanks for all the reviews. I made a new webrev with the comment suggested by Roland and Martin's optimized invalidate(). Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0.to.1/ Full webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.1/ /Mikael > > /Mikael > > On 10/02/2013 02:28 PM, Mikael Gerdin wrote: >> Hi >> >> Please review my fix for the issue discussed in the "G1 question: >> concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing >> list. >> >> I'd like someone from the compiler (and runtime? the interpreter uses >> macroAssembler_*, right?) teams to at least look at the changes to: >> macroAssembler_*.cpp >> c1_Runtime_*.cpp >> graphKit.cpp >> >> Problem description: >> G1 has a race where the concurrent refinement thread may miss object >> references in a dirty card. >> The problem arises if the CPU re-orders the load of the old card value >> (which G1 checks to determine if it can skip the barrier) >> before the store to the actual object. >> If that occurs the concurrent refinement thread may have set the card to >> "clean" and proceeded to scan the card but the java thread may have seen >> the "dirty" value and skipped the post barrier. >> >> Suggested fix: >> * Add a memory fence between the store to a java object and the reading >> of the previous card value. >> * Modify the code for handling young regions so that all writes to young >> regions can skip the fence (since it will never be needed for such >> writes). This introduces a new value in the card table for G1 which >> indicates a young region. >> >> Performance impact: >> * This fix has a negative throughput performance impact of 1-1.5% >> (tested on x86-AMD x86-Intel and SPARC). >> * We may want to try to get rid of this race at some point by >> redesigning G1's post barrier but there is not enough time to do that >> for JDK8. >> >> Performance numbers for x86 platforms can be seen here: >> http://cr.openjdk.java.net/~mgerdin/8014555/perf.txt >> >> Unfortunately the JIRA issue is not externally visible, but the major >> parts of the discussions about this are present in the mailing list >> thread. The bug mostly contains my analysis of the crashes which seems >> to have been caused by this bug. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555 >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8014555/webrev.0 >> > From stefan.karlsson at oracle.com Tue Oct 8 01:58:19 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 08 Oct 2013 10:58:19 +0200 Subject: Review request: 8025996: Track metaspace usage when metaspace is expanded Message-ID: <5253C92B.1030404@oracle.com> http://cr.openjdk.java.net/~stefank/8025996/webrev.00 Previously, the Metaspace memory usage was only tracked at the end of the GCs. This causes the MemoryPoolMXBean.getUsageThreshold(?) functionality to fail for the Metaspace memory pools. This patch adds tracking of Metaspace usage when a new Metachunk is fetched. This patch builds upon the patch in: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011166.html Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces This patch has been tested with the fix for: https://bugs.openjdk.java.net/browse/JDK-7196801 NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 The fix for 7196801 will be done in a separate review request since the test is located in jdk repository and the fix for 8025996 is done in the hotspot repository. thanks, StefanK From volker.simonis at gmail.com Tue Oct 8 10:56:32 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Oct 2013 19:56:32 +0200 Subject: JDK7u, hotspot, CC_INTERP, and COBOL In-Reply-To: <52543E20.1040307@orange.fr> References: <524322D3.4050000@orange.fr> <524F0AF0.5050007@orange.fr> <52543E20.1040307@orange.fr> Message-ID: - reposted without picture - Hi Francis, I think the test you used is good (it generates invokedynamic bytecodes with the ASM library. If you want a better test coverage you could use the regression tests under jdk/test/java/lang/invoke/. Regards, Volker On Tue, Oct 8, 2013 at 7:17 PM, Francis ANDRE < francis.andre.kampbell at orange.fr> wrote: > Hi Volker > > I wanted to test my changes on a simple test that involves InvokeDynamic > using JDK7. I joined the test I found on the internet and also the output > of running this test. I run the same way as before where the assert was > failing before I made the changes. > > Can you have a look to this test and tell me if you consider it as a real > test for the invokedynamic opcode and environment EnableInvokeDynamic as > true which is the default? > > If this ReflectTest.java is not a proper test for testing the > invokedynamic, could you provide me a test you are considering as a test > that the interpreter is running fine? > > > Francis > > > Francis > Le 07/10/2013 10:59, Volker Simonis a ?crit : > > What are your settings for 'EnableInvokeDynamic'? If you use the > default which is EnableInvokeDynamic=true then verifier_max_stack() > doesn't account for extra_stack_entries() and this is wrong because > 'istate->_stack_limit' does (see the comment in our code). > > Your solution probably only seems to work because > 'istate->_stack_limit' on x86 currently does not account for > extra_stack_entries() which is wrong (you probalby won't be able to > run any JSR292 code). I think you'll have to add something similar > like > > // max_stack = method->max_stack(); > // TODO: PPC port: assert(2 == methodOopDesc::sz_max_stack(), > "unexpected field size"); > __ ppc_lhz(max_stack, method_(max_stack)); > > if (EnableInvokeDynamic) { > // Take into account 'extra_stack_entries' needed by method > handles (see method.hpp) > __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries()); > } > > to CppInterpreterGenerator::generate_compute_interpreter_state() on > x86 to make JSR292 work with the CPP interpreter on that platform. > After you did that, you will probably see that the assertion will not > work anymore with verifier_max_stack() and you'll have to use > max_stack() as we did. > > The two different versions of the assertion in our code are only > necessary, if you use a HotSpot 24 with a pre HS24 class library, in > which case EnableInvokeDynamic will be switched off after > CppInterpreterGenerator::generate_compute_interpreter_state was > called. > > Regards, > Volker > > > On Fri, Oct 4, 2013 at 8:37 PM, Francis ANDRE wrote: > > Hi Volker > > I had a look to the CPP-Interpreter you mention in your answer and found out > a somewhat different implementation for verifying the stack size. > > here the snippet from the ppc-aix-potr/jdk7u > #ifdef ASSERT > if (istate->_msg != initialize) { > // We have a problem here if we are running with a pre-hsx24 JDK (for > example during bootstrap) > // because in that case, EnableInvokeDynamic is true by default but will > be later switched off > // if java_lang_invoke_MethodHandle::compute_offsets() detects that the > JDK only has the classes > // for the old JSR292 implementation. > // This leads to a situation where 'istate->_stack_limit' always > accounts for > // methodOopDesc::extra_stack_entries() because it is computed in > // CppInterpreterGenerator::generate_compute_interpreter_state() which > was generated while > // EnableInvokeDynamic was still true. On the other hand, > istate->_method->max_stack() doesn't > // account for extra_stack_entries() anymore because at the time when it > is called > // EnableInvokeDynamic was already set to false. > // So we have a second version of the assertion which handles the case > where EnableInvokeDynamic was > // switched off because of the wrong classes. > if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) { > assert(labs(istate->_stack_base - istate->_stack_limit) == > (istate->_method->max_stack() + 1), "bad stack limit"); > } > else { > const int extra_stack_entries = 2; // MUST match the value in > methodOopDesc::extra_stack_entries() > assert(labs(istate->_stack_base - istate->_stack_limit) == > (istate->_method->max_stack() + extra_stack_entries > + 1), "bad stack limit"); > } > > > On my x86 build, I used this and it seems to work fine also > #ifdef ASSERT > if (istate->_msg != initialize) { > assert(abs(istate->_stack_base - istate->_stack_limit) == > (istate->_method->verifier_max_stack() + 1), "bad stack limit"); > #ifndef SHARK > IA32_ONLY(assert(istate->_stack_limit == istate->_thread->last_Java_sp() > + 1, "wrong")); > #endif // !SHARK > } > > so I am wondering if it is ok to use the verifier_max_stack() function which > seems lighter from the lisibility perspective? > > > > Francis > > Le 30/09/2013 17:37, Volker Simonis a ?crit : > > 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/jdk7uhttp://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 thehttp://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 coleen.phillimore at oracle.com Tue Oct 8 14:19:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 08 Oct 2013 17:19:15 -0400 Subject: Review request: 8025996: Track metaspace usage when metaspace is expanded In-Reply-To: <5253C92B.1030404@oracle.com> References: <5253C92B.1030404@oracle.com> Message-ID: <525476D3.8030706@oracle.com> This looks good. Still working on your other review. Coleen On 10/08/2013 04:58 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8025996/webrev.00 > > Previously, the Metaspace memory usage was only tracked at the end of > the GCs. This causes the MemoryPoolMXBean.getUsageThreshold(?) > functionality to fail for the Metaspace memory pools. This patch adds > tracking of Metaspace usage when a new Metachunk is fetched. > > This patch builds upon the patch in: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011166.html > > Review request: 8024547: MaxMetaspaceSize should limit the committed > memory used by the metaspaces > > This patch has been tested with the fix for: > https://bugs.openjdk.java.net/browse/JDK-7196801 > NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 > > The fix for 7196801 will be done in a separate review request since > the test is located in jdk repository and the fix for 8025996 is done > in the hotspot repository. > > thanks, > StefanK From coleen.phillimore at oracle.com Tue Oct 8 15:33:32 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 08 Oct 2013 18:33:32 -0400 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <5253A46B.2010406@oracle.com> References: <5253A46B.2010406@oracle.com> Message-ID: <5254883C.6050105@oracle.com> In metaspace.cpp: *+ static bool should_reserve_large_pages(size_t bytes) {* *+ if (UseLargePages && UseLargePagesInMetaspace && !os::can_commit_large_page_memory()) {* Isn't UseLargePagesInMetaspace true only if UseLargePages is true? I like assert_size_is_aligned, assert_ptr_is_aligned now you get more info if assert hits too. Below, this comment doesn't seem to match the function name even though inside you test whether you can commit large pages (vs. reserving large pages). Putting a comment about the restriction about can_commit_large_pages should be inside should_reserve_large_pages. It's sort of surprising there when you only look once. It looked like a bug at first. *+ // Decide if large pages should be commmitted when the memory is reserved.* *+ bool large_pages = should_reserve_large_pages(bytes);* *+* *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), large_pages);* 1167 assert(false, "vs_word_size should always be at least _reserve_alignement large."); Typeo. if (is_class()) { assert(false, "We currently don't support more than one VirtualSpace for" " the compressed class space. The initialization of the" " CCS uses another code path and should not hit this path."); return false; } Why not just assert(!is_class(), "with the message") It would take less lines so I can get the rest of the function on the page. And the assert below it? or guarantee() if you are worried about this happening in production (I hope not!) Metachunk* VirtualSpaceList::get_initialization_chunk(size_t chunk_word_size, size_t chunk_bunch) { // Get a chunk from the chunk freelist Metachunk* new_chunk = get_new_chunk(chunk_word_size, chunk_word_size, chunk_bunch); return new_chunk; } Can we just call get_new_chunk from the other get_initialization_chunk and remove this? There are so many functions with the same names, and it looks like this used to do more by the comment. I don't have any other comments now. I think this looks really good and thank you for resolving the MaxMetaspaceSize problem! Coleen On 10/08/2013 02:21 AM, Stefan Karlsson wrote: > Please, review this patch to limit the committed Metaspace memory > against the MaxMetaspaceSize flag. > > http://cr.openjdk.java.net/~stefank/8024547/webrev.00 > > 8024547: MaxMetaspaceSize should limit the committed memory used by > the metaspaces > Reviewed-by: TBD1, TBD2 > > To simplify the code, the patch is strict about the alignments used to > commit and reserve memory in the metaspaces. The Metaspace > VirtualSpaces always have addresses and sizes that are aligned against > Metaspace::reserve_alignment(). The reserve alignment is > os::vm_allocation_granularity() if small pages are used or > os::large_page_size() if large pages are used in the Metaspace. The > memory is always committed in regions that are size aligned against > Metaspace::commit_alignment(). The commit alignment is os:page_size() > if small pages are used or os::large_page_size() if late pages are > used in the Metaspace. The user can specify the flag > -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. > > The flag initialization was moved out of the CollectorPolicy class. > The Metaspace specific flags have been changed to be commit/reserve > aligned instead of using heap specific alignments. > > The output from PrintHeapAtGC has been changed. The redundant "data > space" section has been removed. All of used, capacity, committed and > reserved are printed. Example: > Metaspace used 7644K, capacity 7700K, committed 7808K, reserved > 1056768K > class space used 804K, capacity 822K, committed 896K, reserved > 1048576K > > Thanks go out to the engineers who have helped out with this bug: > Erik, Mikael and Bengt for helping out with parts of the code and > testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes > and providing early feedback. > > thanks, > StefanK From pierre at pingtimeout.fr Wed Oct 2 09:27:35 2013 From: pierre at pingtimeout.fr (Pierre Laporte) Date: Wed, 2 Oct 2013 18:27:35 +0200 Subject: Experimental options in official builds ? Message-ID: Hi guys I just discovered that you can unlock experimental VM options in a regular build of the JDK. This pagetells that unlocking some experimental features can speed up Spring ToolSuite. I made some tests on jdk 1.7.0_25 and 1.7.0_40 on linux machines and I can indeed modify experimental flags. I thought that experimental flags were only for debug build. Is this normal ? $ java -XX:+PrintFlagsFinal -version | grep experimental java version "1.7.0_40" OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build 7.u40_2.4.2-1-x86_64) OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal -version | grep experimental uintx ArrayAllocatorMallocLimit = 18446744073709551615{experimental} intx G1ExpandByPercentOfAvailable = 20 {experimental} ccstr G1LogLevel = {experimental} uintx G1MaxNewSizePercent = 60 {experimental} uintx G1MixedGCLiveThresholdPercent = 65 {experimental} uintx G1NewSizePercent = 5 {experimental} uintx G1OldCSetRegionThresholdPercent = 10 {experimental} bool G1UseConcMarkReferenceProcessing = true {experimental} bool G1UseParallelRSetScanning = true {experimental} bool G1UseParallelRSetUpdating = true {experimental} double ObjectCountCutOffPercent = 0.500000 {experimental} intx PredictedLoadedClassCount = 0 {experimental} bool TrustFinalNonStaticFields = false {experimental} * bool UnlockExperimentalVMOptions := true {experimental} * bool UseCriticalCMSThreadPriority = false {experimental} bool UseCriticalCompilerThreadPriority = false {experimental} bool UseCriticalJavaThreadPriority = false {experimental} bool UseMemSetInBOT = true {experimental} uintx WorkStealingHardSpins = 4096 {experimental} intx WorkStealingSleepMillis = 1 {experimental} uintx WorkStealingSpinToYieldRatio = 10 {experimental} uintx WorkStealingYieldsBeforeSleep = 5000 {experimental} java version "1.7.0_40" OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build 7.u40_2.4.2-1-x86_64) OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal * -XX:+TrustFinalNonStaticFields* -version | grep experimental uintx ArrayAllocatorMallocLimit = 18446744073709551615{experimental} intx G1ExpandByPercentOfAvailable = 20 {experimental} ccstr G1LogLevel = {experimental} uintx G1MaxNewSizePercent = 60 {experimental} uintx G1MixedGCLiveThresholdPercent = 65 {experimental} uintx G1NewSizePercent = 5 {experimental} uintx G1OldCSetRegionThresholdPercent = 10 {experimental} bool G1UseConcMarkReferenceProcessing = true {experimental} bool G1UseParallelRSetScanning = true {experimental} bool G1UseParallelRSetUpdating = true {experimental} double ObjectCountCutOffPercent = 0.500000 {experimental} intx PredictedLoadedClassCount = 0 {experimental} * bool TrustFinalNonStaticFields := true {experimental} bool UnlockExperimentalVMOptions := true {experimental} * bool UseCriticalCMSThreadPriority = false {experimental} bool UseCriticalCompilerThreadPriority = false {experimental} bool UseCriticalJavaThreadPriority = false {experimental} bool UseMemSetInBOT = true {experimental} uintx WorkStealingHardSpins = 4096 {experimental} intx WorkStealingSleepMillis = 1 {experimental} uintx WorkStealingSpinToYieldRatio = 10 {experimental} uintx WorkStealingYieldsBeforeSleep = 5000 {experimental} java version "1.7.0_40" OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build 7.u40_2.4.2-1-x86_64) OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) -- Pierre Laporte @pingtimeout pierre at pingtimeout.fr http://www.pingtimeout.fr/ From rednaxelafx at gmail.com Tue Oct 8 22:07:02 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 9 Oct 2013 13:07:02 +0800 Subject: Experimental options in official builds ? In-Reply-To: References: Message-ID: Hi Pierre, Yes, it is normal. Users would have been warned about using experimental features "at your own risk" by the -XX:+UnlockExperimentalVMOptions flag, so it's considered to be okay. The same goes for diagnostic flags, which is protected by -XX:+UnlockDiagnosticVMOptions. - Kris On Thu, Oct 3, 2013 at 12:27 AM, Pierre Laporte wrote: > Hi guys > > I just discovered that you can unlock experimental VM options in a regular > build of the JDK. > > This page< > http://www.programmingforliving.com/2013/08/how-to-speed-up-eclipse-sts-startup.html > >tells > that unlocking some experimental features can speed up Spring > ToolSuite. I made some tests on jdk 1.7.0_25 and 1.7.0_40 on linux machines > and I can indeed modify experimental flags. I thought that experimental > flags were only for debug build. > > Is this normal ? > > > $ java -XX:+PrintFlagsFinal -version | grep experimental > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > > $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal -version | > grep experimental > uintx ArrayAllocatorMallocLimit = > 18446744073709551615{experimental} > intx G1ExpandByPercentOfAvailable = 20 > {experimental} > ccstr G1LogLevel = > {experimental} > uintx G1MaxNewSizePercent = 60 > {experimental} > uintx G1MixedGCLiveThresholdPercent = 65 > {experimental} > uintx G1NewSizePercent = 5 > {experimental} > uintx G1OldCSetRegionThresholdPercent = 10 > {experimental} > bool G1UseConcMarkReferenceProcessing = true > {experimental} > bool G1UseParallelRSetScanning = true > {experimental} > bool G1UseParallelRSetUpdating = true > {experimental} > double ObjectCountCutOffPercent = 0.500000 > {experimental} > intx PredictedLoadedClassCount = 0 > {experimental} > bool TrustFinalNonStaticFields = false > {experimental} > * bool UnlockExperimentalVMOptions := true > {experimental} * > bool UseCriticalCMSThreadPriority = false > {experimental} > bool UseCriticalCompilerThreadPriority = false > {experimental} > bool UseCriticalJavaThreadPriority = false > {experimental} > bool UseMemSetInBOT = true > {experimental} > uintx WorkStealingHardSpins = 4096 > {experimental} > intx WorkStealingSleepMillis = 1 > {experimental} > uintx WorkStealingSpinToYieldRatio = 10 > {experimental} > uintx WorkStealingYieldsBeforeSleep = 5000 > {experimental} > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > > $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal * > -XX:+TrustFinalNonStaticFields* -version | grep experimental > uintx ArrayAllocatorMallocLimit = > 18446744073709551615{experimental} > intx G1ExpandByPercentOfAvailable = 20 > {experimental} > ccstr G1LogLevel = > {experimental} > uintx G1MaxNewSizePercent = 60 > {experimental} > uintx G1MixedGCLiveThresholdPercent = 65 > {experimental} > uintx G1NewSizePercent = 5 > {experimental} > uintx G1OldCSetRegionThresholdPercent = 10 > {experimental} > bool G1UseConcMarkReferenceProcessing = true > {experimental} > bool G1UseParallelRSetScanning = true > {experimental} > bool G1UseParallelRSetUpdating = true > {experimental} > double ObjectCountCutOffPercent = 0.500000 > {experimental} > intx PredictedLoadedClassCount = 0 > {experimental} > * bool TrustFinalNonStaticFields := true > {experimental} > bool UnlockExperimentalVMOptions := true > {experimental} * > bool UseCriticalCMSThreadPriority = false > {experimental} > bool UseCriticalCompilerThreadPriority = false > {experimental} > bool UseCriticalJavaThreadPriority = false > {experimental} > bool UseMemSetInBOT = true > {experimental} > uintx WorkStealingHardSpins = 4096 > {experimental} > intx WorkStealingSleepMillis = 1 > {experimental} > uintx WorkStealingSpinToYieldRatio = 10 > {experimental} > uintx WorkStealingYieldsBeforeSleep = 5000 > {experimental} > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > -- > > Pierre Laporte > @pingtimeout > pierre at pingtimeout.fr > http://www.pingtimeout.fr/ > From stefan.karlsson at oracle.com Wed Oct 9 00:48:35 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 09:48:35 +0200 Subject: Review request: 8025996: Track metaspace usage when metaspace is expanded In-Reply-To: <525476D3.8030706@oracle.com> References: <5253C92B.1030404@oracle.com> <525476D3.8030706@oracle.com> Message-ID: <52550A53.8000200@oracle.com> On 10/8/13 11:19 PM, Coleen Phillimore wrote: > > This looks good. Still working on your other review. Thanks, Coleen. StefanK > > Coleen > > On 10/08/2013 04:58 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8025996/webrev.00 >> >> Previously, the Metaspace memory usage was only tracked at the end of >> the GCs. This causes the MemoryPoolMXBean.getUsageThreshold(?) >> functionality to fail for the Metaspace memory pools. This patch adds >> tracking of Metaspace usage when a new Metachunk is fetched. >> >> This patch builds upon the patch in: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011166.html >> >> Review request: 8024547: MaxMetaspaceSize should limit the committed >> memory used by the metaspaces >> >> This patch has been tested with the fix for: >> https://bugs.openjdk.java.net/browse/JDK-7196801 >> NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 >> >> The fix for 7196801 will be done in a separate review request since >> the test is located in jdk repository and the fix for 8025996 is done >> in the hotspot repository. >> >> thanks, >> StefanK > From kirk at kodewerk.com Wed Oct 9 01:42:05 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 9 Oct 2013 10:42:05 +0200 Subject: Experimental options in official builds ? In-Reply-To: References: Message-ID: <73D4EB49-30FB-4708-AAE5-AC4ED764EB77@kodewerk.com> this is normal -- Kirk On 2013-10-02, at 6:27 PM, Pierre Laporte wrote: > Hi guys > > I just discovered that you can unlock experimental VM options in a regular > build of the JDK. > > This pagetells > that unlocking some experimental features can speed up Spring > ToolSuite. I made some tests on jdk 1.7.0_25 and 1.7.0_40 on linux machines > and I can indeed modify experimental flags. I thought that experimental > flags were only for debug build. > > Is this normal ? > > > $ java -XX:+PrintFlagsFinal -version | grep experimental > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > > $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal -version | > grep experimental > uintx ArrayAllocatorMallocLimit = > 18446744073709551615{experimental} > intx G1ExpandByPercentOfAvailable = 20 > {experimental} > ccstr G1LogLevel = > {experimental} > uintx G1MaxNewSizePercent = 60 > {experimental} > uintx G1MixedGCLiveThresholdPercent = 65 > {experimental} > uintx G1NewSizePercent = 5 > {experimental} > uintx G1OldCSetRegionThresholdPercent = 10 > {experimental} > bool G1UseConcMarkReferenceProcessing = true > {experimental} > bool G1UseParallelRSetScanning = true > {experimental} > bool G1UseParallelRSetUpdating = true > {experimental} > double ObjectCountCutOffPercent = 0.500000 > {experimental} > intx PredictedLoadedClassCount = 0 > {experimental} > bool TrustFinalNonStaticFields = false > {experimental} > * bool UnlockExperimentalVMOptions := true > {experimental} * > bool UseCriticalCMSThreadPriority = false > {experimental} > bool UseCriticalCompilerThreadPriority = false > {experimental} > bool UseCriticalJavaThreadPriority = false > {experimental} > bool UseMemSetInBOT = true > {experimental} > uintx WorkStealingHardSpins = 4096 > {experimental} > intx WorkStealingSleepMillis = 1 > {experimental} > uintx WorkStealingSpinToYieldRatio = 10 > {experimental} > uintx WorkStealingYieldsBeforeSleep = 5000 > {experimental} > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > > $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal * > -XX:+TrustFinalNonStaticFields* -version | grep experimental > uintx ArrayAllocatorMallocLimit = > 18446744073709551615{experimental} > intx G1ExpandByPercentOfAvailable = 20 > {experimental} > ccstr G1LogLevel = > {experimental} > uintx G1MaxNewSizePercent = 60 > {experimental} > uintx G1MixedGCLiveThresholdPercent = 65 > {experimental} > uintx G1NewSizePercent = 5 > {experimental} > uintx G1OldCSetRegionThresholdPercent = 10 > {experimental} > bool G1UseConcMarkReferenceProcessing = true > {experimental} > bool G1UseParallelRSetScanning = true > {experimental} > bool G1UseParallelRSetUpdating = true > {experimental} > double ObjectCountCutOffPercent = 0.500000 > {experimental} > intx PredictedLoadedClassCount = 0 > {experimental} > * bool TrustFinalNonStaticFields := true > {experimental} > bool UnlockExperimentalVMOptions := true > {experimental} * > bool UseCriticalCMSThreadPriority = false > {experimental} > bool UseCriticalCompilerThreadPriority = false > {experimental} > bool UseCriticalJavaThreadPriority = false > {experimental} > bool UseMemSetInBOT = true > {experimental} > uintx WorkStealingHardSpins = 4096 > {experimental} > intx WorkStealingSleepMillis = 1 > {experimental} > uintx WorkStealingSpinToYieldRatio = 10 > {experimental} > uintx WorkStealingYieldsBeforeSleep = 5000 > {experimental} > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > -- > > Pierre Laporte > @pingtimeout > pierre at pingtimeout.fr > http://www.pingtimeout.fr/ From jaromir.hamala at gmail.com Wed Oct 9 01:46:54 2013 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Wed, 9 Oct 2013 09:46:54 +0100 Subject: Experimental options in official builds ? In-Reply-To: References: Message-ID: Hi, check this out: http://stas-blogspot.blogspot.com/2011/07/most-complete-list-of-xx-options-for.html Cheers, Jaromir On Wed, Oct 2, 2013 at 5:27 PM, Pierre Laporte wrote: > Hi guys > > I just discovered that you can unlock experimental VM options in a regular > build of the JDK. > > This page< > http://www.programmingforliving.com/2013/08/how-to-speed-up-eclipse-sts-startup.html > >tells > that unlocking some experimental features can speed up Spring > ToolSuite. I made some tests on jdk 1.7.0_25 and 1.7.0_40 on linux machines > and I can indeed modify experimental flags. I thought that experimental > flags were only for debug build. > > Is this normal ? > > > $ java -XX:+PrintFlagsFinal -version | grep experimental > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > > $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal -version | > grep experimental > uintx ArrayAllocatorMallocLimit = > 18446744073709551615{experimental} > intx G1ExpandByPercentOfAvailable = 20 > {experimental} > ccstr G1LogLevel = > {experimental} > uintx G1MaxNewSizePercent = 60 > {experimental} > uintx G1MixedGCLiveThresholdPercent = 65 > {experimental} > uintx G1NewSizePercent = 5 > {experimental} > uintx G1OldCSetRegionThresholdPercent = 10 > {experimental} > bool G1UseConcMarkReferenceProcessing = true > {experimental} > bool G1UseParallelRSetScanning = true > {experimental} > bool G1UseParallelRSetUpdating = true > {experimental} > double ObjectCountCutOffPercent = 0.500000 > {experimental} > intx PredictedLoadedClassCount = 0 > {experimental} > bool TrustFinalNonStaticFields = false > {experimental} > * bool UnlockExperimentalVMOptions := true > {experimental} * > bool UseCriticalCMSThreadPriority = false > {experimental} > bool UseCriticalCompilerThreadPriority = false > {experimental} > bool UseCriticalJavaThreadPriority = false > {experimental} > bool UseMemSetInBOT = true > {experimental} > uintx WorkStealingHardSpins = 4096 > {experimental} > intx WorkStealingSleepMillis = 1 > {experimental} > uintx WorkStealingSpinToYieldRatio = 10 > {experimental} > uintx WorkStealingYieldsBeforeSleep = 5000 > {experimental} > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > > $ java *-XX:+UnlockExperimentalVMOptions* -XX:+PrintFlagsFinal * > -XX:+TrustFinalNonStaticFields* -version | grep experimental > uintx ArrayAllocatorMallocLimit = > 18446744073709551615{experimental} > intx G1ExpandByPercentOfAvailable = 20 > {experimental} > ccstr G1LogLevel = > {experimental} > uintx G1MaxNewSizePercent = 60 > {experimental} > uintx G1MixedGCLiveThresholdPercent = 65 > {experimental} > uintx G1NewSizePercent = 5 > {experimental} > uintx G1OldCSetRegionThresholdPercent = 10 > {experimental} > bool G1UseConcMarkReferenceProcessing = true > {experimental} > bool G1UseParallelRSetScanning = true > {experimental} > bool G1UseParallelRSetUpdating = true > {experimental} > double ObjectCountCutOffPercent = 0.500000 > {experimental} > intx PredictedLoadedClassCount = 0 > {experimental} > * bool TrustFinalNonStaticFields := true > {experimental} > bool UnlockExperimentalVMOptions := true > {experimental} * > bool UseCriticalCMSThreadPriority = false > {experimental} > bool UseCriticalCompilerThreadPriority = false > {experimental} > bool UseCriticalJavaThreadPriority = false > {experimental} > bool UseMemSetInBOT = true > {experimental} > uintx WorkStealingHardSpins = 4096 > {experimental} > intx WorkStealingSleepMillis = 1 > {experimental} > uintx WorkStealingSpinToYieldRatio = 10 > {experimental} > uintx WorkStealingYieldsBeforeSleep = 5000 > {experimental} > java version "1.7.0_40" > OpenJDK Runtime Environment (IcedTea 2.4.2) (ArchLinux build > 7.u40_2.4.2-1-x86_64) > OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode) > > -- > > Pierre Laporte > @pingtimeout > pierre at pingtimeout.fr > http://www.pingtimeout.fr/ > -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry From stefan.karlsson at oracle.com Wed Oct 9 02:15:06 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 11:15:06 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <5254FE0E.30706@oracle.com> References: <5253A46B.2010406@oracle.com> <5254883C.6050105@oracle.com> <5254FE0E.30706@oracle.com> Message-ID: <52551E9A.50101@oracle.com> Here's the fixes for the issues I agreed with you on: http://cr.openjdk.java.net/~stefank/8024547/webrev.01.delta/ Here's the full patch: http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ Jon suggested that I should document in globals.hpp that UseLargePagesInMetaspace is only used when UseLargePages is true. thanks, StefanK On 10/9/13 8:56 AM, Stefan Karlsson wrote: > > On 2013-10-09 00:33, Coleen Phillimore wrote: >> >> In metaspace.cpp: >> >> *+ static bool should_reserve_large_pages(size_t bytes) {* >> *+ if (UseLargePages && UseLargePagesInMetaspace && >> !os::can_commit_large_page_memory()) {* >> >> Isn't UseLargePagesInMetaspace true only if UseLargePages is true? > > Not in the current version of the code. > >> >> I like assert_size_is_aligned, assert_ptr_is_aligned now you get more >> info if assert hits too. >> >> Below, this comment doesn't seem to match the function name even >> though inside you test whether you can commit large pages (vs. >> reserving large pages). Putting a comment about the restriction >> about can_commit_large_pages should be inside >> should_reserve_large_pages. It's sort of surprising there when you >> only look once. It looked like a bug at first. >> >> *+ // Decide if large pages should be commmitted when the memory >> is reserved.* >> *+ bool large_pages = should_reserve_large_pages(bytes);* >> *+* >> *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), >> large_pages);* > > OK. How about a longer name: > should_commit_large_pages_when_reserving(bytes), and get rid of/move > the comment? > >> >> >> >> 1167 assert(false, "vs_word_size should always be at least >> _reserve_alignement large."); >> >> >> Typeo. > > Thanks. > >> >> if (is_class()) { >> assert(false, "We currently don't support more than one >> VirtualSpace for" >> " the compressed class space. The initialization of >> the" >> " CCS uses another code path and should not hit >> this path."); >> return false; >> } >> >> Why not just assert(!is_class(), "with the message") It would take >> less lines so I can get the rest of the function on the page. >> >> And the assert below it? or guarantee() if you are worried about >> this happening in production (I hope not!) > > It's just defensive programming. If we end up hitting this code path > in production builds, the code will still work as it's currently written. > >> >> >> Metachunk* VirtualSpaceList::get_initialization_chunk(size_t >> chunk_word_size, >> size_t >> chunk_bunch) { >> // Get a chunk from the chunk freelist >> Metachunk* new_chunk = get_new_chunk(chunk_word_size, >> chunk_word_size, >> chunk_bunch); >> return new_chunk; >> } >> >> Can we just call get_new_chunk from the other >> get_initialization_chunk and remove this? There are so many >> functions with the same names, and it looks like this used to do more >> by the comment. > > Will do. > >> >> I don't have any other comments now. I think this looks really good >> and thank you for resolving the MaxMetaspaceSize problem! > > Thanks, Coleen! > > StefanK > >> >> Coleen >> >> On 10/08/2013 02:21 AM, Stefan Karlsson wrote: >>> Please, review this patch to limit the committed Metaspace memory >>> against the MaxMetaspaceSize flag. >>> >>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>> >>> 8024547: MaxMetaspaceSize should limit the committed memory used by >>> the metaspaces >>> Reviewed-by: TBD1, TBD2 >>> >>> To simplify the code, the patch is strict about the alignments used >>> to commit and reserve memory in the metaspaces. The Metaspace >>> VirtualSpaces always have addresses and sizes that are aligned >>> against Metaspace::reserve_alignment(). The reserve alignment is >>> os::vm_allocation_granularity() if small pages are used or >>> os::large_page_size() if large pages are used in the Metaspace. The >>> memory is always committed in regions that are size aligned against >>> Metaspace::commit_alignment(). The commit alignment is >>> os:page_size() if small pages are used or os::large_page_size() if >>> late pages are used in the Metaspace. The user can specify the flag >>> -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. >>> >>> The flag initialization was moved out of the CollectorPolicy class. >>> The Metaspace specific flags have been changed to be commit/reserve >>> aligned instead of using heap specific alignments. >>> >>> The output from PrintHeapAtGC has been changed. The redundant "data >>> space" section has been removed. All of used, capacity, committed >>> and reserved are printed. Example: >>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>> reserved 1056768K >>> class space used 804K, capacity 822K, committed 896K, reserved >>> 1048576K >>> >>> Thanks go out to the engineers who have helped out with this bug: >>> Erik, Mikael and Bengt for helping out with parts of the code and >>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes >>> and providing early feedback. >>> >>> thanks, >>> StefanK >> > From stefan.karlssonn at oracle.com Tue Oct 8 23:56:14 2013 From: stefan.karlssonn at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 08:56:14 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <5254883C.6050105@oracle.com> References: <5253A46B.2010406@oracle.com> <5254883C.6050105@oracle.com> Message-ID: <5254FE0E.30706@oracle.com> On 2013-10-09 00:33, Coleen Phillimore wrote: > > In metaspace.cpp: > > *+ static bool should_reserve_large_pages(size_t bytes) {* > *+ if (UseLargePages && UseLargePagesInMetaspace && > !os::can_commit_large_page_memory()) {* > > Isn't UseLargePagesInMetaspace true only if UseLargePages is true? Not in the current version of the code. > > I like assert_size_is_aligned, assert_ptr_is_aligned now you get more > info if assert hits too. > > Below, this comment doesn't seem to match the function name even > though inside you test whether you can commit large pages (vs. > reserving large pages). Putting a comment about the restriction about > can_commit_large_pages should be inside should_reserve_large_pages. > It's sort of surprising there when you only look once. It looked like > a bug at first. > > *+ // Decide if large pages should be commmitted when the memory > is reserved.* > *+ bool large_pages = should_reserve_large_pages(bytes);* > *+* > *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), > large_pages);* OK. How about a longer name: should_commit_large_pages_when_reserving(bytes), and get rid of/move the comment? > > > > 1167 assert(false, "vs_word_size should always be at least > _reserve_alignement large."); > > > Typeo. Thanks. > > if (is_class()) { > assert(false, "We currently don't support more than one > VirtualSpace for" > " the compressed class space. The initialization of > the" > " CCS uses another code path and should not hit this > path."); > return false; > } > > Why not just assert(!is_class(), "with the message") It would take > less lines so I can get the rest of the function on the page. > > And the assert below it? or guarantee() if you are worried about this > happening in production (I hope not!) It's just defensive programming. If we end up hitting this code path in production builds, the code will still work as it's currently written. > > > Metachunk* VirtualSpaceList::get_initialization_chunk(size_t > chunk_word_size, > size_t > chunk_bunch) { > // Get a chunk from the chunk freelist > Metachunk* new_chunk = get_new_chunk(chunk_word_size, > chunk_word_size, > chunk_bunch); > return new_chunk; > } > > Can we just call get_new_chunk from the other get_initialization_chunk > and remove this? There are so many functions with the same names, and > it looks like this used to do more by the comment. Will do. > > I don't have any other comments now. I think this looks really good > and thank you for resolving the MaxMetaspaceSize problem! Thanks, Coleen! StefanK > > Coleen > > On 10/08/2013 02:21 AM, Stefan Karlsson wrote: >> Please, review this patch to limit the committed Metaspace memory >> against the MaxMetaspaceSize flag. >> >> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >> >> 8024547: MaxMetaspaceSize should limit the committed memory used by >> the metaspaces >> Reviewed-by: TBD1, TBD2 >> >> To simplify the code, the patch is strict about the alignments used >> to commit and reserve memory in the metaspaces. The Metaspace >> VirtualSpaces always have addresses and sizes that are aligned >> against Metaspace::reserve_alignment(). The reserve alignment is >> os::vm_allocation_granularity() if small pages are used or >> os::large_page_size() if large pages are used in the Metaspace. The >> memory is always committed in regions that are size aligned against >> Metaspace::commit_alignment(). The commit alignment is os:page_size() >> if small pages are used or os::large_page_size() if late pages are >> used in the Metaspace. The user can specify the flag >> -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. >> >> The flag initialization was moved out of the CollectorPolicy class. >> The Metaspace specific flags have been changed to be commit/reserve >> aligned instead of using heap specific alignments. >> >> The output from PrintHeapAtGC has been changed. The redundant "data >> space" section has been removed. All of used, capacity, committed and >> reserved are printed. Example: >> Metaspace used 7644K, capacity 7700K, committed 7808K, >> reserved 1056768K >> class space used 804K, capacity 822K, committed 896K, reserved >> 1048576K >> >> Thanks go out to the engineers who have helped out with this bug: >> Erik, Mikael and Bengt for helping out with parts of the code and >> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes >> and providing early feedback. >> >> thanks, >> StefanK > From bengt.rutisson at oracle.com Wed Oct 9 03:17:41 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 09 Oct 2013 12:17:41 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <5253A46B.2010406@oracle.com> References: <5253A46B.2010406@oracle.com> Message-ID: <52552D45.10509@oracle.com> Hi Stefan, I think think this looks really good. Below are a couple of minor nits. Feel free to address them or ignore them. I'm fine with you pushing the existing changeset. I don't think "special" is a very good name for signaling that we have committed all large pages up front. But since that is the name used in other code I find it a little confusing to suddenly call it "pre_committed" in metaspace.cpp. However, "pre_committed" is a better name, so I'm ok with keeping is_pre_committed(). But in that case we should probably use it instead of _rs.special() in VirtualSpaceNode::initialize(). size_t pre_committed_size = _rs.special() ? _rs.size() : 0; In MetaspaceGC::delta_capacity_until_GC(). Why do we pick min_delta in this case? if (delta <= min_delta) { delta = min_delta; } Why not expand with max_delta for the same reason as a slightly larger delta? if (delta <= max_delta) { // Don't want to hit the high water mark on the next // allocation so make the delta greater than just enough // for this allocation. delta = max_delta; } Why did you move Metadebug::deallocate_chunk_a_lot(this, grow_chunks_by_words); out into it's own if section? if (next != NULL) { Metadebug::deallocate_chunk_a_lot(this, grow_chunks_by_words); } MetaWord* mem = NULL; // If a chunk was available, add it to the in-use chunk list // and do an allocation from it. if (next != NULL) { // Add to this manager's list of chunks in use. add_chunk(next, false); mem = next->allocate(word_size); } return mem; Thanks, Bengt On 10/8/13 8:21 AM, Stefan Karlsson wrote: > Please, review this patch to limit the committed Metaspace memory > against the MaxMetaspaceSize flag. > > http://cr.openjdk.java.net/~stefank/8024547/webrev.00 > > 8024547: MaxMetaspaceSize should limit the committed memory used by > the metaspaces > Reviewed-by: TBD1, TBD2 > > To simplify the code, the patch is strict about the alignments used to > commit and reserve memory in the metaspaces. The Metaspace > VirtualSpaces always have addresses and sizes that are aligned against > Metaspace::reserve_alignment(). The reserve alignment is > os::vm_allocation_granularity() if small pages are used or > os::large_page_size() if large pages are used in the Metaspace. The > memory is always committed in regions that are size aligned against > Metaspace::commit_alignment(). The commit alignment is os:page_size() > if small pages are used or os::large_page_size() if late pages are > used in the Metaspace. The user can specify the flag > -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. > > The flag initialization was moved out of the CollectorPolicy class. > The Metaspace specific flags have been changed to be commit/reserve > aligned instead of using heap specific alignments. > > The output from PrintHeapAtGC has been changed. The redundant "data > space" section has been removed. All of used, capacity, committed and > reserved are printed. Example: > Metaspace used 7644K, capacity 7700K, committed 7808K, reserved > 1056768K > class space used 804K, capacity 822K, committed 896K, reserved > 1048576K > > Thanks go out to the engineers who have helped out with this bug: > Erik, Mikael and Bengt for helping out with parts of the code and > testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes > and providing early feedback. > > thanks, > StefanK From stefan.karlsson at oracle.com Wed Oct 9 05:16:39 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 14:16:39 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <52552D45.10509@oracle.com> References: <5253A46B.2010406@oracle.com> <52552D45.10509@oracle.com> Message-ID: <52554927.2050803@oracle.com> On 10/9/13 12:17 PM, Bengt Rutisson wrote: > > Hi Stefan, > > I think think this looks really good. Thanks. > > Below are a couple of minor nits. Feel free to address them or ignore > them. I'm fine with you pushing the existing changeset. > > > > I don't think "special" is a very good name for signaling that we have > committed all large pages up front. But since that is the name used in > other code I find it a little confusing to suddenly call it > "pre_committed" in metaspace.cpp. However, "pre_committed" is a better > name, so I'm ok with keeping is_pre_committed(). OK. My motivation to create the is_pre_committed() function was to make the code in VirtualSpaceNode::expand_by easier for the casual reader to understand. > But in that case we should probably use it instead of _rs.special() in > VirtualSpaceNode::initialize(). > > size_t pre_committed_size = _rs.special() ? _rs.size() : 0; VirtualSpaceNode::is_pre_committed() operates on _virtual_space and not _rs, so that won't work. > > > In MetaspaceGC::delta_capacity_until_GC(). Why do we pick min_delta in > this case? > > if (delta <= min_delta) { > delta = min_delta; > } > > Why not expand with max_delta for the same reason as a slightly larger > delta? > > if (delta <= max_delta) { > // Don't want to hit the high water mark on the next > // allocation so make the delta greater than just enough > // for this allocation. > delta = max_delta; > } I don't know. The logic in the file pre-exists this patch. > > > > Why did you move Metadebug::deallocate_chunk_a_lot(this, > grow_chunks_by_words); out into it's own if section? > > > if (next != NULL) { > Metadebug::deallocate_chunk_a_lot(this, grow_chunks_by_words); > } > > MetaWord* mem = NULL; > > // If a chunk was available, add it to the in-use chunk list > // and do an allocation from it. > if (next != NULL) { > // Add to this manager's list of chunks in use. > add_chunk(next, false); > mem = next->allocate(word_size); > } > > return mem; I wanted to separate out the debugging code to make it easier to read the real allocation code in the if-statement. thanks, StefanK > > Thanks, > Bengt > > > > On 10/8/13 8:21 AM, Stefan Karlsson wrote: >> Please, review this patch to limit the committed Metaspace memory >> against the MaxMetaspaceSize flag. >> >> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >> >> 8024547: MaxMetaspaceSize should limit the committed memory used by >> the metaspaces >> Reviewed-by: TBD1, TBD2 >> >> To simplify the code, the patch is strict about the alignments used >> to commit and reserve memory in the metaspaces. The Metaspace >> VirtualSpaces always have addresses and sizes that are aligned >> against Metaspace::reserve_alignment(). The reserve alignment is >> os::vm_allocation_granularity() if small pages are used or >> os::large_page_size() if large pages are used in the Metaspace. The >> memory is always committed in regions that are size aligned against >> Metaspace::commit_alignment(). The commit alignment is os:page_size() >> if small pages are used or os::large_page_size() if late pages are >> used in the Metaspace. The user can specify the flag >> -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. >> >> The flag initialization was moved out of the CollectorPolicy class. >> The Metaspace specific flags have been changed to be commit/reserve >> aligned instead of using heap specific alignments. >> >> The output from PrintHeapAtGC has been changed. The redundant "data >> space" section has been removed. All of used, capacity, committed and >> reserved are printed. Example: >> Metaspace used 7644K, capacity 7700K, committed 7808K, >> reserved 1056768K >> class space used 804K, capacity 822K, committed 896K, reserved >> 1048576K >> >> Thanks go out to the engineers who have helped out with this bug: >> Erik, Mikael and Bengt for helping out with parts of the code and >> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes >> and providing early feedback. >> >> thanks, >> StefanK > From bengt.rutisson at oracle.com Wed Oct 9 05:37:57 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 09 Oct 2013 14:37:57 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <52554927.2050803@oracle.com> References: <5253A46B.2010406@oracle.com> <52552D45.10509@oracle.com> <52554927.2050803@oracle.com> Message-ID: <52554E25.40506@oracle.com> Hi Stefan, On 10/9/13 2:16 PM, Stefan Karlsson wrote: > On 10/9/13 12:17 PM, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> I think think this looks really good. > > Thanks. > >> >> Below are a couple of minor nits. Feel free to address them or ignore >> them. I'm fine with you pushing the existing changeset. >> >> >> >> I don't think "special" is a very good name for signaling that we >> have committed all large pages up front. But since that is the name >> used in other code I find it a little confusing to suddenly call it >> "pre_committed" in metaspace.cpp. However, "pre_committed" is a >> better name, so I'm ok with keeping is_pre_committed(). > > OK. My motivation to create the is_pre_committed() function was to > make the code in VirtualSpaceNode::expand_by easier for the casual > reader to understand. OK. > >> But in that case we should probably use it instead of _rs.special() >> in VirtualSpaceNode::initialize(). >> >> size_t pre_committed_size = _rs.special() ? _rs.size() : 0; > > VirtualSpaceNode::is_pre_committed() operates on _virtual_space and > not _rs, so that won't work. Right, but _virtual_space._special is initialized to _rs.special in VirtualSpace::initialize_with_granularity(), so shouldn't they be the same? > >> >> >> In MetaspaceGC::delta_capacity_until_GC(). Why do we pick min_delta >> in this case? >> >> if (delta <= min_delta) { >> delta = min_delta; >> } >> >> Why not expand with max_delta for the same reason as a slightly >> larger delta? >> >> if (delta <= max_delta) { >> // Don't want to hit the high water mark on the next >> // allocation so make the delta greater than just enough >> // for this allocation. >> delta = max_delta; >> } > > I don't know. The logic in the file pre-exists this patch. OK. It just looks odd to me. But it should not be fixed in this patch I guess. > >> >> >> >> Why did you move Metadebug::deallocate_chunk_a_lot(this, >> grow_chunks_by_words); out into it's own if section? >> >> >> if (next != NULL) { >> Metadebug::deallocate_chunk_a_lot(this, grow_chunks_by_words); >> } >> >> MetaWord* mem = NULL; >> >> // If a chunk was available, add it to the in-use chunk list >> // and do an allocation from it. >> if (next != NULL) { >> // Add to this manager's list of chunks in use. >> add_chunk(next, false); >> mem = next->allocate(word_size); >> } >> >> return mem; > > I wanted to separate out the debugging code to make it easier to read > the real allocation code in the if-statement. That's fine. I was just curious. And as I said earlier, I'm fine with this being pushed as is. Bengt > > thanks, > StefanK >> >> Thanks, >> Bengt >> >> >> >> On 10/8/13 8:21 AM, Stefan Karlsson wrote: >>> Please, review this patch to limit the committed Metaspace memory >>> against the MaxMetaspaceSize flag. >>> >>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>> >>> 8024547: MaxMetaspaceSize should limit the committed memory used by >>> the metaspaces >>> Reviewed-by: TBD1, TBD2 >>> >>> To simplify the code, the patch is strict about the alignments used >>> to commit and reserve memory in the metaspaces. The Metaspace >>> VirtualSpaces always have addresses and sizes that are aligned >>> against Metaspace::reserve_alignment(). The reserve alignment is >>> os::vm_allocation_granularity() if small pages are used or >>> os::large_page_size() if large pages are used in the Metaspace. The >>> memory is always committed in regions that are size aligned against >>> Metaspace::commit_alignment(). The commit alignment is >>> os:page_size() if small pages are used or os::large_page_size() if >>> late pages are used in the Metaspace. The user can specify the flag >>> -XX:+UseLargePagesInMetaspace to turn on large pages in the metaspaces. >>> >>> The flag initialization was moved out of the CollectorPolicy class. >>> The Metaspace specific flags have been changed to be commit/reserve >>> aligned instead of using heap specific alignments. >>> >>> The output from PrintHeapAtGC has been changed. The redundant "data >>> space" section has been removed. All of used, capacity, committed >>> and reserved are printed. Example: >>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>> reserved 1056768K >>> class space used 804K, capacity 822K, committed 896K, reserved >>> 1048576K >>> >>> Thanks go out to the engineers who have helped out with this bug: >>> Erik, Mikael and Bengt for helping out with parts of the code and >>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the changes >>> and providing early feedback. >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Wed Oct 9 05:46:11 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 14:46:11 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <52554E25.40506@oracle.com> References: <5253A46B.2010406@oracle.com> <52552D45.10509@oracle.com> <52554927.2050803@oracle.com> <52554E25.40506@oracle.com> Message-ID: <52555013.1040006@oracle.com> On 10/9/13 2:37 PM, Bengt Rutisson wrote: > > Hi Stefan, > > On 10/9/13 2:16 PM, Stefan Karlsson wrote: >> On 10/9/13 12:17 PM, Bengt Rutisson wrote: >>> >>> Hi Stefan, >>> >>> I think think this looks really good. >> >> Thanks. >> >>> >>> Below are a couple of minor nits. Feel free to address them or >>> ignore them. I'm fine with you pushing the existing changeset. >>> >>> >>> >>> I don't think "special" is a very good name for signaling that we >>> have committed all large pages up front. But since that is the name >>> used in other code I find it a little confusing to suddenly call it >>> "pre_committed" in metaspace.cpp. However, "pre_committed" is a >>> better name, so I'm ok with keeping is_pre_committed(). >> >> OK. My motivation to create the is_pre_committed() function was to >> make the code in VirtualSpaceNode::expand_by easier for the casual >> reader to understand. > > OK. > >> >>> But in that case we should probably use it instead of _rs.special() >>> in VirtualSpaceNode::initialize(). >>> >>> size_t pre_committed_size = _rs.special() ? _rs.size() : 0; >> >> VirtualSpaceNode::is_pre_committed() operates on _virtual_space and >> not _rs, so that won't work. > > Right, but _virtual_space._special is initialized to _rs.special in > VirtualSpace::initialize_with_granularity(), so shouldn't they be the > same? The code looks like this: size_t pre_committed_size = _rs.special() ? _rs.size() : 0; bool result = virtual_space()->initialize_with_granularity(_rs, pre_committed_size, Metaspace::commit_alignment()); I can't use _virtual_space->special() since _virtual_space has not been initialized at that point. > >> >>> >>> >>> In MetaspaceGC::delta_capacity_until_GC(). Why do we pick min_delta >>> in this case? >>> >>> if (delta <= min_delta) { >>> delta = min_delta; >>> } >>> >>> Why not expand with max_delta for the same reason as a slightly >>> larger delta? >>> >>> if (delta <= max_delta) { >>> // Don't want to hit the high water mark on the next >>> // allocation so make the delta greater than just enough >>> // for this allocation. >>> delta = max_delta; >>> } >> >> I don't know. The logic in the file pre-exists this patch. > > OK. It just looks odd to me. But it should not be fixed in this patch > I guess. > >> >>> >>> >>> >>> Why did you move Metadebug::deallocate_chunk_a_lot(this, >>> grow_chunks_by_words); out into it's own if section? >>> >>> >>> if (next != NULL) { >>> Metadebug::deallocate_chunk_a_lot(this, grow_chunks_by_words); >>> } >>> >>> MetaWord* mem = NULL; >>> >>> // If a chunk was available, add it to the in-use chunk list >>> // and do an allocation from it. >>> if (next != NULL) { >>> // Add to this manager's list of chunks in use. >>> add_chunk(next, false); >>> mem = next->allocate(word_size); >>> } >>> >>> return mem; >> >> I wanted to separate out the debugging code to make it easier to read >> the real allocation code in the if-statement. > > That's fine. I was just curious. > > And as I said earlier, I'm fine with this being pushed as is. Thanks, StefanK > > Bengt > >> >> thanks, >> StefanK >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> On 10/8/13 8:21 AM, Stefan Karlsson wrote: >>>> Please, review this patch to limit the committed Metaspace memory >>>> against the MaxMetaspaceSize flag. >>>> >>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>>> >>>> 8024547: MaxMetaspaceSize should limit the committed memory used by >>>> the metaspaces >>>> Reviewed-by: TBD1, TBD2 >>>> >>>> To simplify the code, the patch is strict about the alignments used >>>> to commit and reserve memory in the metaspaces. The Metaspace >>>> VirtualSpaces always have addresses and sizes that are aligned >>>> against Metaspace::reserve_alignment(). The reserve alignment is >>>> os::vm_allocation_granularity() if small pages are used or >>>> os::large_page_size() if large pages are used in the Metaspace. The >>>> memory is always committed in regions that are size aligned against >>>> Metaspace::commit_alignment(). The commit alignment is >>>> os:page_size() if small pages are used or os::large_page_size() if >>>> late pages are used in the Metaspace. The user can specify the flag >>>> -XX:+UseLargePagesInMetaspace to turn on large pages in the >>>> metaspaces. >>>> >>>> The flag initialization was moved out of the CollectorPolicy class. >>>> The Metaspace specific flags have been changed to be commit/reserve >>>> aligned instead of using heap specific alignments. >>>> >>>> The output from PrintHeapAtGC has been changed. The redundant "data >>>> space" section has been removed. All of used, capacity, committed >>>> and reserved are printed. Example: >>>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>>> reserved 1056768K >>>> class space used 804K, capacity 822K, committed 896K, reserved >>>> 1048576K >>>> >>>> Thanks go out to the engineers who have helped out with this bug: >>>> Erik, Mikael and Bengt for helping out with parts of the code and >>>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the >>>> changes and providing early feedback. >>>> >>>> thanks, >>>> StefanK >>> >> > From coleen.phillimore at oracle.com Wed Oct 9 06:04:59 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 09 Oct 2013 09:04:59 -0400 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <52551E9A.50101@oracle.com> References: <5253A46B.2010406@oracle.com> <5254883C.6050105@oracle.com> <5254FE0E.30706@oracle.com> <52551E9A.50101@oracle.com> Message-ID: <5255547B.7000906@oracle.com> Thanks - fine on all issues, ship it! Coleen On 10/9/2013 5:15 AM, Stefan Karlsson wrote: > Here's the fixes for the issues I agreed with you on: > http://cr.openjdk.java.net/~stefank/8024547/webrev.01.delta/ > > Here's the full patch: > http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ > > Jon suggested that I should document in globals.hpp that > UseLargePagesInMetaspace is only used when UseLargePages is true. > > thanks, > StefanK > > On 10/9/13 8:56 AM, Stefan Karlsson wrote: >> >> On 2013-10-09 00:33, Coleen Phillimore wrote: >>> >>> In metaspace.cpp: >>> >>> *+ static bool should_reserve_large_pages(size_t bytes) {* >>> *+ if (UseLargePages && UseLargePagesInMetaspace && >>> !os::can_commit_large_page_memory()) {* >>> >>> Isn't UseLargePagesInMetaspace true only if UseLargePages is true? >> >> Not in the current version of the code. >> >>> >>> I like assert_size_is_aligned, assert_ptr_is_aligned now you get >>> more info if assert hits too. >>> >>> Below, this comment doesn't seem to match the function name even >>> though inside you test whether you can commit large pages (vs. >>> reserving large pages). Putting a comment about the restriction >>> about can_commit_large_pages should be inside >>> should_reserve_large_pages. It's sort of surprising there when you >>> only look once. It looked like a bug at first. >>> >>> *+ // Decide if large pages should be commmitted when the >>> memory is reserved.* >>> *+ bool large_pages = should_reserve_large_pages(bytes);* >>> *+* >>> *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), >>> large_pages);* >> >> OK. How about a longer name: >> should_commit_large_pages_when_reserving(bytes), and get rid of/move >> the comment? >> >>> >>> >>> >>> 1167 assert(false, "vs_word_size should always be at least >>> _reserve_alignement large."); >>> >>> >>> Typeo. >> >> Thanks. >> >>> >>> if (is_class()) { >>> assert(false, "We currently don't support more than one >>> VirtualSpace for" >>> " the compressed class space. The initialization >>> of the" >>> " CCS uses another code path and should not hit >>> this path."); >>> return false; >>> } >>> >>> Why not just assert(!is_class(), "with the message") It would take >>> less lines so I can get the rest of the function on the page. >>> >>> And the assert below it? or guarantee() if you are worried about >>> this happening in production (I hope not!) >> >> It's just defensive programming. If we end up hitting this code path >> in production builds, the code will still work as it's currently >> written. >> >>> >>> >>> Metachunk* VirtualSpaceList::get_initialization_chunk(size_t >>> chunk_word_size, >>> size_t >>> chunk_bunch) { >>> // Get a chunk from the chunk freelist >>> Metachunk* new_chunk = get_new_chunk(chunk_word_size, >>> chunk_word_size, >>> chunk_bunch); >>> return new_chunk; >>> } >>> >>> Can we just call get_new_chunk from the other >>> get_initialization_chunk and remove this? There are so many >>> functions with the same names, and it looks like this used to do >>> more by the comment. >> >> Will do. >> >>> >>> I don't have any other comments now. I think this looks really good >>> and thank you for resolving the MaxMetaspaceSize problem! >> >> Thanks, Coleen! >> >> StefanK >> >>> >>> Coleen >>> >>> On 10/08/2013 02:21 AM, Stefan Karlsson wrote: >>>> Please, review this patch to limit the committed Metaspace memory >>>> against the MaxMetaspaceSize flag. >>>> >>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>>> >>>> 8024547: MaxMetaspaceSize should limit the committed memory used by >>>> the metaspaces >>>> Reviewed-by: TBD1, TBD2 >>>> >>>> To simplify the code, the patch is strict about the alignments used >>>> to commit and reserve memory in the metaspaces. The Metaspace >>>> VirtualSpaces always have addresses and sizes that are aligned >>>> against Metaspace::reserve_alignment(). The reserve alignment is >>>> os::vm_allocation_granularity() if small pages are used or >>>> os::large_page_size() if large pages are used in the Metaspace. The >>>> memory is always committed in regions that are size aligned against >>>> Metaspace::commit_alignment(). The commit alignment is >>>> os:page_size() if small pages are used or os::large_page_size() if >>>> late pages are used in the Metaspace. The user can specify the flag >>>> -XX:+UseLargePagesInMetaspace to turn on large pages in the >>>> metaspaces. >>>> >>>> The flag initialization was moved out of the CollectorPolicy class. >>>> The Metaspace specific flags have been changed to be commit/reserve >>>> aligned instead of using heap specific alignments. >>>> >>>> The output from PrintHeapAtGC has been changed. The redundant "data >>>> space" section has been removed. All of used, capacity, committed >>>> and reserved are printed. Example: >>>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>>> reserved 1056768K >>>> class space used 804K, capacity 822K, committed 896K, reserved >>>> 1048576K >>>> >>>> Thanks go out to the engineers who have helped out with this bug: >>>> Erik, Mikael and Bengt for helping out with parts of the code and >>>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the >>>> changes and providing early feedback. >>>> >>>> thanks, >>>> StefanK >>> >> > From bengt.rutisson at oracle.com Wed Oct 9 06:12:38 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 09 Oct 2013 15:12:38 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <52555013.1040006@oracle.com> References: <5253A46B.2010406@oracle.com> <52552D45.10509@oracle.com> <52554927.2050803@oracle.com> <52554E25.40506@oracle.com> <52555013.1040006@oracle.com> Message-ID: <52555646.2070204@oracle.com> On 10/9/13 2:46 PM, Stefan Karlsson wrote: > On 10/9/13 2:37 PM, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> On 10/9/13 2:16 PM, Stefan Karlsson wrote: >>> On 10/9/13 12:17 PM, Bengt Rutisson wrote: >>>> >>>> Hi Stefan, >>>> >>>> I think think this looks really good. >>> >>> Thanks. >>> >>>> >>>> Below are a couple of minor nits. Feel free to address them or >>>> ignore them. I'm fine with you pushing the existing changeset. >>>> >>>> >>>> >>>> I don't think "special" is a very good name for signaling that we >>>> have committed all large pages up front. But since that is the name >>>> used in other code I find it a little confusing to suddenly call it >>>> "pre_committed" in metaspace.cpp. However, "pre_committed" is a >>>> better name, so I'm ok with keeping is_pre_committed(). >>> >>> OK. My motivation to create the is_pre_committed() function was to >>> make the code in VirtualSpaceNode::expand_by easier for the casual >>> reader to understand. >> >> OK. >> >>> >>>> But in that case we should probably use it instead of _rs.special() >>>> in VirtualSpaceNode::initialize(). >>>> >>>> size_t pre_committed_size = _rs.special() ? _rs.size() : 0; >>> >>> VirtualSpaceNode::is_pre_committed() operates on _virtual_space and >>> not _rs, so that won't work. >> >> Right, but _virtual_space._special is initialized to _rs.special in >> VirtualSpace::initialize_with_granularity(), so shouldn't they be the >> same? > > The code looks like this: > size_t pre_committed_size = _rs.special() ? _rs.size() : 0; > > bool result = virtual_space()->initialize_with_granularity(_rs, > pre_committed_size, > Metaspace::commit_alignment()); > > I can't use _virtual_space->special() since _virtual_space has not > been initialized at that point. Ah. Of course. I give up ;-) Ship it! Bengt > >> >>> >>>> >>>> >>>> In MetaspaceGC::delta_capacity_until_GC(). Why do we pick min_delta >>>> in this case? >>>> >>>> if (delta <= min_delta) { >>>> delta = min_delta; >>>> } >>>> >>>> Why not expand with max_delta for the same reason as a slightly >>>> larger delta? >>>> >>>> if (delta <= max_delta) { >>>> // Don't want to hit the high water mark on the next >>>> // allocation so make the delta greater than just enough >>>> // for this allocation. >>>> delta = max_delta; >>>> } >>> >>> I don't know. The logic in the file pre-exists this patch. >> >> OK. It just looks odd to me. But it should not be fixed in this patch >> I guess. >> >>> >>>> >>>> >>>> >>>> Why did you move Metadebug::deallocate_chunk_a_lot(this, >>>> grow_chunks_by_words); out into it's own if section? >>>> >>>> >>>> if (next != NULL) { >>>> Metadebug::deallocate_chunk_a_lot(this, grow_chunks_by_words); >>>> } >>>> >>>> MetaWord* mem = NULL; >>>> >>>> // If a chunk was available, add it to the in-use chunk list >>>> // and do an allocation from it. >>>> if (next != NULL) { >>>> // Add to this manager's list of chunks in use. >>>> add_chunk(next, false); >>>> mem = next->allocate(word_size); >>>> } >>>> >>>> return mem; >>> >>> I wanted to separate out the debugging code to make it easier to >>> read the real allocation code in the if-statement. >> >> That's fine. I was just curious. >> >> And as I said earlier, I'm fine with this being pushed as is. > > Thanks, > StefanK > >> >> Bengt >> >>> >>> thanks, >>> StefanK >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>> On 10/8/13 8:21 AM, Stefan Karlsson wrote: >>>>> Please, review this patch to limit the committed Metaspace memory >>>>> against the MaxMetaspaceSize flag. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>>>> >>>>> 8024547: MaxMetaspaceSize should limit the committed memory used >>>>> by the metaspaces >>>>> Reviewed-by: TBD1, TBD2 >>>>> >>>>> To simplify the code, the patch is strict about the alignments >>>>> used to commit and reserve memory in the metaspaces. The Metaspace >>>>> VirtualSpaces always have addresses and sizes that are aligned >>>>> against Metaspace::reserve_alignment(). The reserve alignment is >>>>> os::vm_allocation_granularity() if small pages are used or >>>>> os::large_page_size() if large pages are used in the Metaspace. >>>>> The memory is always committed in regions that are size aligned >>>>> against Metaspace::commit_alignment(). The commit alignment is >>>>> os:page_size() if small pages are used or os::large_page_size() if >>>>> late pages are used in the Metaspace. The user can specify the >>>>> flag -XX:+UseLargePagesInMetaspace to turn on large pages in the >>>>> metaspaces. >>>>> >>>>> The flag initialization was moved out of the CollectorPolicy >>>>> class. The Metaspace specific flags have been changed to be >>>>> commit/reserve aligned instead of using heap specific alignments. >>>>> >>>>> The output from PrintHeapAtGC has been changed. The redundant >>>>> "data space" section has been removed. All of used, capacity, >>>>> committed and reserved are printed. Example: >>>>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>>>> reserved 1056768K >>>>> class space used 804K, capacity 822K, committed 896K, >>>>> reserved 1048576K >>>>> >>>>> Thanks go out to the engineers who have helped out with this bug: >>>>> Erik, Mikael and Bengt for helping out with parts of the code and >>>>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the >>>>> changes and providing early feedback. >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From stefan.karlsson at oracle.com Wed Oct 9 06:19:23 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 15:19:23 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <5255547B.7000906@oracle.com> References: <5253A46B.2010406@oracle.com> <5254883C.6050105@oracle.com> <5254FE0E.30706@oracle.com> <52551E9A.50101@oracle.com> <5255547B.7000906@oracle.com> Message-ID: <525557DB.50806@oracle.com> I just talked to Jon. He proposed that I should rename UseLargePagesInMetaspace to UseLargePagesMetaspace. What do you think? diff -r 1ada3c6d8cdd src/share/vm/memory/metaspace.cpp --- a/src/share/vm/memory/metaspace.cpp Wed Oct 09 10:40:12 2013 +0200 +++ b/src/share/vm/memory/metaspace.cpp Wed Oct 09 15:16:40 2013 +0200 @@ -362,7 +362,7 @@ // Decide if large pages should be committed when the memory is reserved. static bool should_commit_large_pages_when_reserving(size_t bytes) { - if (UseLargePages && UseLargePagesInMetaspace && !os::can_commit_large_page_memory()) { + if (UseLargePages && UseLargePagesMetaspace && !os::can_commit_large_page_memory()) { size_t words = bytes / BytesPerWord; bool is_class = false; // We never reserve large pages for the class space. if (MetaspaceGC::can_expand(words, is_class) && @@ -3054,11 +3054,11 @@ void Metaspace::ergo_initialize() { if (DumpSharedSpaces) { // Using large pages when dumping the shared archive is currently not implemented. - FLAG_SET_ERGO(bool, UseLargePagesInMetaspace, false); + FLAG_SET_ERGO(bool, UseLargePagesMetaspace, false); } size_t page_size = os::vm_page_size(); - if (UseLargePages && UseLargePagesInMetaspace) { + if (UseLargePages && UseLargePagesMetaspace) { page_size = os::large_page_size(); } diff -r 1ada3c6d8cdd src/share/vm/runtime/globals.hpp --- a/src/share/vm/runtime/globals.hpp Wed Oct 09 10:40:12 2013 +0200 +++ b/src/share/vm/runtime/globals.hpp Wed Oct 09 15:16:40 2013 +0200 @@ -500,8 +500,9 @@ develop(bool, LargePagesIndividualAllocationInjectError, false, \ "Fail large pages individual allocation") \ \ - product(bool, UseLargePagesInMetaspace, false, \ - "Use large page memory in metaspace") \ + product(bool, UseLargePagesMetaspace, false, \ + "Use large page memory in the Metaspace. " \ + "Only used if UseLargePages is enabled.") \ \ develop(bool, TracePageSizes, false, \ "Trace page size selection and usage.") \ I'm going to push this when the flag naming is resolved. thanks, StefanK On 10/9/13 3:04 PM, Coleen Phillimore wrote: > > Thanks - fine on all issues, ship it! > Coleen > > On 10/9/2013 5:15 AM, Stefan Karlsson wrote: >> Here's the fixes for the issues I agreed with you on: >> http://cr.openjdk.java.net/~stefank/8024547/webrev.01.delta/ >> >> Here's the full patch: >> http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ >> >> Jon suggested that I should document in globals.hpp that >> UseLargePagesInMetaspace is only used when UseLargePages is true. >> >> thanks, >> StefanK >> >> On 10/9/13 8:56 AM, Stefan Karlsson wrote: >>> >>> On 2013-10-09 00:33, Coleen Phillimore wrote: >>>> >>>> In metaspace.cpp: >>>> >>>> *+ static bool should_reserve_large_pages(size_t bytes) {* >>>> *+ if (UseLargePages && UseLargePagesInMetaspace && >>>> !os::can_commit_large_page_memory()) {* >>>> >>>> Isn't UseLargePagesInMetaspace true only if UseLargePages is true? >>> >>> Not in the current version of the code. >>> >>>> >>>> I like assert_size_is_aligned, assert_ptr_is_aligned now you get >>>> more info if assert hits too. >>>> >>>> Below, this comment doesn't seem to match the function name even >>>> though inside you test whether you can commit large pages (vs. >>>> reserving large pages). Putting a comment about the restriction >>>> about can_commit_large_pages should be inside >>>> should_reserve_large_pages. It's sort of surprising there when >>>> you only look once. It looked like a bug at first. >>>> >>>> *+ // Decide if large pages should be commmitted when the >>>> memory is reserved.* >>>> *+ bool large_pages = should_reserve_large_pages(bytes);* >>>> *+* >>>> *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), >>>> large_pages);* >>> >>> OK. How about a longer name: >>> should_commit_large_pages_when_reserving(bytes), and get rid of/move >>> the comment? >>> >>>> >>>> >>>> >>>> 1167 assert(false, "vs_word_size should always be at least >>>> _reserve_alignement large."); >>>> >>>> >>>> Typeo. >>> >>> Thanks. >>> >>>> >>>> if (is_class()) { >>>> assert(false, "We currently don't support more than one >>>> VirtualSpace for" >>>> " the compressed class space. The initialization >>>> of the" >>>> " CCS uses another code path and should not hit >>>> this path."); >>>> return false; >>>> } >>>> >>>> Why not just assert(!is_class(), "with the message") It would take >>>> less lines so I can get the rest of the function on the page. >>>> >>>> And the assert below it? or guarantee() if you are worried about >>>> this happening in production (I hope not!) >>> >>> It's just defensive programming. If we end up hitting this code path >>> in production builds, the code will still work as it's currently >>> written. >>> >>>> >>>> >>>> Metachunk* VirtualSpaceList::get_initialization_chunk(size_t >>>> chunk_word_size, >>>> size_t >>>> chunk_bunch) { >>>> // Get a chunk from the chunk freelist >>>> Metachunk* new_chunk = get_new_chunk(chunk_word_size, >>>> chunk_word_size, >>>> chunk_bunch); >>>> return new_chunk; >>>> } >>>> >>>> Can we just call get_new_chunk from the other >>>> get_initialization_chunk and remove this? There are so many >>>> functions with the same names, and it looks like this used to do >>>> more by the comment. >>> >>> Will do. >>> >>>> >>>> I don't have any other comments now. I think this looks really >>>> good and thank you for resolving the MaxMetaspaceSize problem! >>> >>> Thanks, Coleen! >>> >>> StefanK >>> >>>> >>>> Coleen >>>> >>>> On 10/08/2013 02:21 AM, Stefan Karlsson wrote: >>>>> Please, review this patch to limit the committed Metaspace memory >>>>> against the MaxMetaspaceSize flag. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>>>> >>>>> 8024547: MaxMetaspaceSize should limit the committed memory used >>>>> by the metaspaces >>>>> Reviewed-by: TBD1, TBD2 >>>>> >>>>> To simplify the code, the patch is strict about the alignments >>>>> used to commit and reserve memory in the metaspaces. The Metaspace >>>>> VirtualSpaces always have addresses and sizes that are aligned >>>>> against Metaspace::reserve_alignment(). The reserve alignment is >>>>> os::vm_allocation_granularity() if small pages are used or >>>>> os::large_page_size() if large pages are used in the Metaspace. >>>>> The memory is always committed in regions that are size aligned >>>>> against Metaspace::commit_alignment(). The commit alignment is >>>>> os:page_size() if small pages are used or os::large_page_size() if >>>>> late pages are used in the Metaspace. The user can specify the >>>>> flag -XX:+UseLargePagesInMetaspace to turn on large pages in the >>>>> metaspaces. >>>>> >>>>> The flag initialization was moved out of the CollectorPolicy >>>>> class. The Metaspace specific flags have been changed to be >>>>> commit/reserve aligned instead of using heap specific alignments. >>>>> >>>>> The output from PrintHeapAtGC has been changed. The redundant >>>>> "data space" section has been removed. All of used, capacity, >>>>> committed and reserved are printed. Example: >>>>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>>>> reserved 1056768K >>>>> class space used 804K, capacity 822K, committed 896K, >>>>> reserved 1048576K >>>>> >>>>> Thanks go out to the engineers who have helped out with this bug: >>>>> Erik, Mikael and Bengt for helping out with parts of the code and >>>>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the >>>>> changes and providing early feedback. >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From coleen.phillimore at oracle.com Wed Oct 9 06:24:16 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 09 Oct 2013 09:24:16 -0400 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <525557DB.50806@oracle.com> References: <5253A46B.2010406@oracle.com> <5254883C.6050105@oracle.com> <5254FE0E.30706@oracle.com> <52551E9A.50101@oracle.com> <5255547B.7000906@oracle.com> <525557DB.50806@oracle.com> Message-ID: <52555900.8090100@oracle.com> On 10/9/2013 9:19 AM, Stefan Karlsson wrote: > I just talked to Jon. He proposed that I should rename > UseLargePagesInMetaspace to UseLargePagesMetaspace. What do you think? Sure, if Jon think so. > Jon suggested that I should document in globals.hpp that > UseLargePagesInMetaspace is only used when UseLargePages is true. Don't we enforce this in arguments.cpp? Coleen > > diff -r 1ada3c6d8cdd src/share/vm/memory/metaspace.cpp > --- a/src/share/vm/memory/metaspace.cpp Wed Oct 09 10:40:12 2013 +0200 > +++ b/src/share/vm/memory/metaspace.cpp Wed Oct 09 15:16:40 2013 +0200 > @@ -362,7 +362,7 @@ > > // Decide if large pages should be committed when the memory is > reserved. > static bool should_commit_large_pages_when_reserving(size_t bytes) { > - if (UseLargePages && UseLargePagesInMetaspace && > !os::can_commit_large_page_memory()) { > + if (UseLargePages && UseLargePagesMetaspace && > !os::can_commit_large_page_memory()) { > size_t words = bytes / BytesPerWord; > bool is_class = false; // We never reserve large pages for the > class space. > if (MetaspaceGC::can_expand(words, is_class) && > @@ -3054,11 +3054,11 @@ > void Metaspace::ergo_initialize() { > if (DumpSharedSpaces) { > // Using large pages when dumping the shared archive is currently > not implemented. > - FLAG_SET_ERGO(bool, UseLargePagesInMetaspace, false); > + FLAG_SET_ERGO(bool, UseLargePagesMetaspace, false); > } > > size_t page_size = os::vm_page_size(); > - if (UseLargePages && UseLargePagesInMetaspace) { > + if (UseLargePages && UseLargePagesMetaspace) { > page_size = os::large_page_size(); > } > > diff -r 1ada3c6d8cdd src/share/vm/runtime/globals.hpp > --- a/src/share/vm/runtime/globals.hpp Wed Oct 09 10:40:12 2013 +0200 > +++ b/src/share/vm/runtime/globals.hpp Wed Oct 09 15:16:40 2013 +0200 > @@ -500,8 +500,9 @@ > develop(bool, LargePagesIndividualAllocationInjectError, > false, \ > "Fail large pages individual > allocation") \ > \ > - product(bool, UseLargePagesInMetaspace, > false, \ > - "Use large page memory in > metaspace") \ > + product(bool, UseLargePagesMetaspace, > false, \ > + "Use large page memory in the Metaspace. > " \ > + "Only used if UseLargePages is > enabled.") \ > \ > develop(bool, TracePageSizes, > false, \ > "Trace page size selection and > usage.") \ > > I'm going to push this when the flag naming is resolved. > > thanks, > StefanK > > On 10/9/13 3:04 PM, Coleen Phillimore wrote: >> >> Thanks - fine on all issues, ship it! >> Coleen >> >> On 10/9/2013 5:15 AM, Stefan Karlsson wrote: >>> Here's the fixes for the issues I agreed with you on: >>> http://cr.openjdk.java.net/~stefank/8024547/webrev.01.delta/ >>> >>> Here's the full patch: >>> http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ >>> >>> Jon suggested that I should document in globals.hpp that >>> UseLargePagesInMetaspace is only used when UseLargePages is true. >>> >>> thanks, >>> StefanK >>> >>> On 10/9/13 8:56 AM, Stefan Karlsson wrote: >>>> >>>> On 2013-10-09 00:33, Coleen Phillimore wrote: >>>>> >>>>> In metaspace.cpp: >>>>> >>>>> *+ static bool should_reserve_large_pages(size_t bytes) {* >>>>> *+ if (UseLargePages && UseLargePagesInMetaspace && >>>>> !os::can_commit_large_page_memory()) {* >>>>> >>>>> Isn't UseLargePagesInMetaspace true only if UseLargePages is true? >>>> >>>> Not in the current version of the code. >>>> >>>>> >>>>> I like assert_size_is_aligned, assert_ptr_is_aligned now you get >>>>> more info if assert hits too. >>>>> >>>>> Below, this comment doesn't seem to match the function name even >>>>> though inside you test whether you can commit large pages (vs. >>>>> reserving large pages). Putting a comment about the restriction >>>>> about can_commit_large_pages should be inside >>>>> should_reserve_large_pages. It's sort of surprising there when >>>>> you only look once. It looked like a bug at first. >>>>> >>>>> *+ // Decide if large pages should be commmitted when the >>>>> memory is reserved.* >>>>> *+ bool large_pages = should_reserve_large_pages(bytes);* >>>>> *+* >>>>> *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), >>>>> large_pages);* >>>> >>>> OK. How about a longer name: >>>> should_commit_large_pages_when_reserving(bytes), and get rid >>>> of/move the comment? >>>> >>>>> >>>>> >>>>> >>>>> 1167 assert(false, "vs_word_size should always be at least >>>>> _reserve_alignement large."); >>>>> >>>>> >>>>> Typeo. >>>> >>>> Thanks. >>>> >>>>> >>>>> if (is_class()) { >>>>> assert(false, "We currently don't support more than one >>>>> VirtualSpace for" >>>>> " the compressed class space. The initialization >>>>> of the" >>>>> " CCS uses another code path and should not hit >>>>> this path."); >>>>> return false; >>>>> } >>>>> >>>>> Why not just assert(!is_class(), "with the message") It would >>>>> take less lines so I can get the rest of the function on the page. >>>>> >>>>> And the assert below it? or guarantee() if you are worried about >>>>> this happening in production (I hope not!) >>>> >>>> It's just defensive programming. If we end up hitting this code >>>> path in production builds, the code will still work as it's >>>> currently written. >>>> >>>>> >>>>> >>>>> Metachunk* VirtualSpaceList::get_initialization_chunk(size_t >>>>> chunk_word_size, >>>>> size_t chunk_bunch) { >>>>> // Get a chunk from the chunk freelist >>>>> Metachunk* new_chunk = get_new_chunk(chunk_word_size, >>>>> chunk_word_size, >>>>> chunk_bunch); >>>>> return new_chunk; >>>>> } >>>>> >>>>> Can we just call get_new_chunk from the other >>>>> get_initialization_chunk and remove this? There are so many >>>>> functions with the same names, and it looks like this used to do >>>>> more by the comment. >>>> >>>> Will do. >>>> >>>>> >>>>> I don't have any other comments now. I think this looks really >>>>> good and thank you for resolving the MaxMetaspaceSize problem! >>>> >>>> Thanks, Coleen! >>>> >>>> StefanK >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 10/08/2013 02:21 AM, Stefan Karlsson wrote: >>>>>> Please, review this patch to limit the committed Metaspace memory >>>>>> against the MaxMetaspaceSize flag. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>>>>> >>>>>> 8024547: MaxMetaspaceSize should limit the committed memory used >>>>>> by the metaspaces >>>>>> Reviewed-by: TBD1, TBD2 >>>>>> >>>>>> To simplify the code, the patch is strict about the alignments >>>>>> used to commit and reserve memory in the metaspaces. The >>>>>> Metaspace VirtualSpaces always have addresses and sizes that are >>>>>> aligned against Metaspace::reserve_alignment(). The reserve >>>>>> alignment is os::vm_allocation_granularity() if small pages are >>>>>> used or os::large_page_size() if large pages are used in the >>>>>> Metaspace. The memory is always committed in regions that are >>>>>> size aligned against Metaspace::commit_alignment(). The commit >>>>>> alignment is os:page_size() if small pages are used or >>>>>> os::large_page_size() if late pages are used in the Metaspace. >>>>>> The user can specify the flag -XX:+UseLargePagesInMetaspace to >>>>>> turn on large pages in the metaspaces. >>>>>> >>>>>> The flag initialization was moved out of the CollectorPolicy >>>>>> class. The Metaspace specific flags have been changed to be >>>>>> commit/reserve aligned instead of using heap specific alignments. >>>>>> >>>>>> The output from PrintHeapAtGC has been changed. The redundant >>>>>> "data space" section has been removed. All of used, capacity, >>>>>> committed and reserved are printed. Example: >>>>>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>>>>> reserved 1056768K >>>>>> class space used 804K, capacity 822K, committed 896K, >>>>>> reserved 1048576K >>>>>> >>>>>> Thanks go out to the engineers who have helped out with this bug: >>>>>> Erik, Mikael and Bengt for helping out with parts of the code and >>>>>> testing. Bengt, Coleen, Jesper and Jon for pre-reviewing the >>>>>> changes and providing early feedback. >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>> >>>> >>> >> > From stefan.karlsson at oracle.com Wed Oct 9 06:42:02 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Oct 2013 15:42:02 +0200 Subject: Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces In-Reply-To: <52555900.8090100@oracle.com> References: <5253A46B.2010406@oracle.com> <5254883C.6050105@oracle.com> <5254FE0E.30706@oracle.com> <52551E9A.50101@oracle.com> <5255547B.7000906@oracle.com> <525557DB.50806@oracle.com> <52555900.8090100@oracle.com> Message-ID: <52555D2A.8080200@oracle.com> On 10/9/13 3:24 PM, Coleen Phillimore wrote: > On 10/9/2013 9:19 AM, Stefan Karlsson wrote: >> I just talked to Jon. He proposed that I should rename >> UseLargePagesInMetaspace to UseLargePagesMetaspace. What do you think? > > Sure, if Jon think so. > >> Jon suggested that I should document in globals.hpp that >> UseLargePagesInMetaspace is only used when UseLargePages is true. > > Don't we enforce this in arguments.cpp? No. StefanK > > Coleen > >> >> diff -r 1ada3c6d8cdd src/share/vm/memory/metaspace.cpp >> --- a/src/share/vm/memory/metaspace.cpp Wed Oct 09 10:40:12 2013 >> +0200 >> +++ b/src/share/vm/memory/metaspace.cpp Wed Oct 09 15:16:40 2013 >> +0200 >> @@ -362,7 +362,7 @@ >> >> // Decide if large pages should be committed when the memory is >> reserved. >> static bool should_commit_large_pages_when_reserving(size_t bytes) { >> - if (UseLargePages && UseLargePagesInMetaspace && >> !os::can_commit_large_page_memory()) { >> + if (UseLargePages && UseLargePagesMetaspace && >> !os::can_commit_large_page_memory()) { >> size_t words = bytes / BytesPerWord; >> bool is_class = false; // We never reserve large pages for the >> class space. >> if (MetaspaceGC::can_expand(words, is_class) && >> @@ -3054,11 +3054,11 @@ >> void Metaspace::ergo_initialize() { >> if (DumpSharedSpaces) { >> // Using large pages when dumping the shared archive is >> currently not implemented. >> - FLAG_SET_ERGO(bool, UseLargePagesInMetaspace, false); >> + FLAG_SET_ERGO(bool, UseLargePagesMetaspace, false); >> } >> >> size_t page_size = os::vm_page_size(); >> - if (UseLargePages && UseLargePagesInMetaspace) { >> + if (UseLargePages && UseLargePagesMetaspace) { >> page_size = os::large_page_size(); >> } >> >> diff -r 1ada3c6d8cdd src/share/vm/runtime/globals.hpp >> --- a/src/share/vm/runtime/globals.hpp Wed Oct 09 10:40:12 2013 +0200 >> +++ b/src/share/vm/runtime/globals.hpp Wed Oct 09 15:16:40 2013 +0200 >> @@ -500,8 +500,9 @@ >> develop(bool, LargePagesIndividualAllocationInjectError, >> false, \ >> "Fail large pages individual >> allocation") \ >> \ >> - product(bool, UseLargePagesInMetaspace, >> false, \ >> - "Use large page memory in >> metaspace") \ >> + product(bool, UseLargePagesMetaspace, >> false, \ >> + "Use large page memory in the Metaspace. >> " \ >> + "Only used if UseLargePages is >> enabled.") \ >> \ >> develop(bool, TracePageSizes, >> false, \ >> "Trace page size selection and >> usage.") \ >> >> I'm going to push this when the flag naming is resolved. >> >> thanks, >> StefanK >> >> On 10/9/13 3:04 PM, Coleen Phillimore wrote: >>> >>> Thanks - fine on all issues, ship it! >>> Coleen >>> >>> On 10/9/2013 5:15 AM, Stefan Karlsson wrote: >>>> Here's the fixes for the issues I agreed with you on: >>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.01.delta/ >>>> >>>> Here's the full patch: >>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.01/ >>>> >>>> Jon suggested that I should document in globals.hpp that >>>> UseLargePagesInMetaspace is only used when UseLargePages is true. >>>> >>>> thanks, >>>> StefanK >>>> >>>> On 10/9/13 8:56 AM, Stefan Karlsson wrote: >>>>> >>>>> On 2013-10-09 00:33, Coleen Phillimore wrote: >>>>>> >>>>>> In metaspace.cpp: >>>>>> >>>>>> *+ static bool should_reserve_large_pages(size_t bytes) {* >>>>>> *+ if (UseLargePages && UseLargePagesInMetaspace && >>>>>> !os::can_commit_large_page_memory()) {* >>>>>> >>>>>> Isn't UseLargePagesInMetaspace true only if UseLargePages is true? >>>>> >>>>> Not in the current version of the code. >>>>> >>>>>> >>>>>> I like assert_size_is_aligned, assert_ptr_is_aligned now you get >>>>>> more info if assert hits too. >>>>>> >>>>>> Below, this comment doesn't seem to match the function name even >>>>>> though inside you test whether you can commit large pages (vs. >>>>>> reserving large pages). Putting a comment about the restriction >>>>>> about can_commit_large_pages should be inside >>>>>> should_reserve_large_pages. It's sort of surprising there when >>>>>> you only look once. It looked like a bug at first. >>>>>> >>>>>> *+ // Decide if large pages should be commmitted when the >>>>>> memory is reserved.* >>>>>> *+ bool large_pages = should_reserve_large_pages(bytes);* >>>>>> *+* >>>>>> *+ _rs = ReservedSpace(bytes, Metaspace::reserve_alignment(), >>>>>> large_pages);* >>>>> >>>>> OK. How about a longer name: >>>>> should_commit_large_pages_when_reserving(bytes), and get rid >>>>> of/move the comment? >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 1167 assert(false, "vs_word_size should always be at least >>>>>> _reserve_alignement large."); >>>>>> >>>>>> >>>>>> Typeo. >>>>> >>>>> Thanks. >>>>> >>>>>> >>>>>> if (is_class()) { >>>>>> assert(false, "We currently don't support more than one >>>>>> VirtualSpace for" >>>>>> " the compressed class space. The >>>>>> initialization of the" >>>>>> " CCS uses another code path and should not hit >>>>>> this path."); >>>>>> return false; >>>>>> } >>>>>> >>>>>> Why not just assert(!is_class(), "with the message") It would >>>>>> take less lines so I can get the rest of the function on the page. >>>>>> >>>>>> And the assert below it? or guarantee() if you are worried about >>>>>> this happening in production (I hope not!) >>>>> >>>>> It's just defensive programming. If we end up hitting this code >>>>> path in production builds, the code will still work as it's >>>>> currently written. >>>>> >>>>>> >>>>>> >>>>>> Metachunk* VirtualSpaceList::get_initialization_chunk(size_t >>>>>> chunk_word_size, >>>>>> size_t chunk_bunch) { >>>>>> // Get a chunk from the chunk freelist >>>>>> Metachunk* new_chunk = get_new_chunk(chunk_word_size, >>>>>> chunk_word_size, >>>>>> chunk_bunch); >>>>>> return new_chunk; >>>>>> } >>>>>> >>>>>> Can we just call get_new_chunk from the other >>>>>> get_initialization_chunk and remove this? There are so many >>>>>> functions with the same names, and it looks like this used to do >>>>>> more by the comment. >>>>> >>>>> Will do. >>>>> >>>>>> >>>>>> I don't have any other comments now. I think this looks really >>>>>> good and thank you for resolving the MaxMetaspaceSize problem! >>>>> >>>>> Thanks, Coleen! >>>>> >>>>> StefanK >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 10/08/2013 02:21 AM, Stefan Karlsson wrote: >>>>>>> Please, review this patch to limit the committed Metaspace >>>>>>> memory against the MaxMetaspaceSize flag. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8024547/webrev.00 >>>>>>> >>>>>>> 8024547: MaxMetaspaceSize should limit the committed memory used >>>>>>> by the metaspaces >>>>>>> Reviewed-by: TBD1, TBD2 >>>>>>> >>>>>>> To simplify the code, the patch is strict about the alignments >>>>>>> used to commit and reserve memory in the metaspaces. The >>>>>>> Metaspace VirtualSpaces always have addresses and sizes that are >>>>>>> aligned against Metaspace::reserve_alignment(). The reserve >>>>>>> alignment is os::vm_allocation_granularity() if small pages are >>>>>>> used or os::large_page_size() if large pages are used in the >>>>>>> Metaspace. The memory is always committed in regions that are >>>>>>> size aligned against Metaspace::commit_alignment(). The commit >>>>>>> alignment is os:page_size() if small pages are used or >>>>>>> os::large_page_size() if late pages are used in the Metaspace. >>>>>>> The user can specify the flag -XX:+UseLargePagesInMetaspace to >>>>>>> turn on large pages in the metaspaces. >>>>>>> >>>>>>> The flag initialization was moved out of the CollectorPolicy >>>>>>> class. The Metaspace specific flags have been changed to be >>>>>>> commit/reserve aligned instead of using heap specific alignments. >>>>>>> >>>>>>> The output from PrintHeapAtGC has been changed. The redundant >>>>>>> "data space" section has been removed. All of used, capacity, >>>>>>> committed and reserved are printed. Example: >>>>>>> Metaspace used 7644K, capacity 7700K, committed 7808K, >>>>>>> reserved 1056768K >>>>>>> class space used 804K, capacity 822K, committed 896K, >>>>>>> reserved 1048576K >>>>>>> >>>>>>> Thanks go out to the engineers who have helped out with this >>>>>>> bug: Erik, Mikael and Bengt for helping out with parts of the >>>>>>> code and testing. Bengt, Coleen, Jesper and Jon for >>>>>>> pre-reviewing the changes and providing early feedback. >>>>>>> >>>>>>> thanks, >>>>>>> StefanK >>>>>> >>>>> >>>> >>> >> > From john.coomes at oracle.com Thu Oct 10 10:31:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:31:41 +0000 Subject: hg: hsx/hotspot-main: 5 new changesets Message-ID: <20131010173142.5B2B362F10@hg.openjdk.java.net> Changeset: feb4f2d97042 Author: ihse Date: 2013-10-03 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/feb4f2d97042 8008944: Correct typos Reviewed-by: tbell, erikj ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/JavaCompilation.gmk Changeset: d23177734b28 Author: thurka Date: 2013-10-07 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d23177734b28 8025920: webrev.ksh does not provide any details about changes in zip files Summary: Add support for diffs for zip files Reviewed-by: ksrini, chegar ! make/scripts/webrev.ksh Changeset: 9b102ab97693 Author: erikj Date: 2013-10-07 18:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9b102ab97693 8005924: Make it possible to set both --with-user-release-suffix and --with-build-number Reviewed-by: ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: d086227bfc45 Author: katleman Date: 2013-10-08 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d086227bfc45 Merge Changeset: 82a36c5c4eaf Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/82a36c5c4eaf Added tag jdk8-b111 for changeset d086227bfc45 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:31:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:31:55 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b111 for changeset 85c1c94e7235 Message-ID: <20131010173159.B221262F11@hg.openjdk.java.net> Changeset: d7e478820c56 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d7e478820c56 Added tag jdk8-b111 for changeset 85c1c94e7235 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:32:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:32:32 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b111 for changeset 17ee0d3e97fd Message-ID: <20131010173255.F2CCA62F12@hg.openjdk.java.net> Changeset: a4622ff1462b Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a4622ff1462b Added tag jdk8-b111 for changeset 17ee0d3e97fd ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:33:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:33:55 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b111 for changeset 32edc7a2c866 Message-ID: <20131010173404.4041B62F14@hg.openjdk.java.net> Changeset: fc94ce4b899e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/fc94ce4b899e Added tag jdk8-b111 for changeset 32edc7a2c866 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:34:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:34:46 +0000 Subject: hg: hsx/hotspot-main/jdk: 4 new changesets Message-ID: <20131010173655.1774562F15@hg.openjdk.java.net> Changeset: 88597d465e48 Author: ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author: erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 719befd87c7b Author: katleman Date: 2013-10-08 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/719befd87c7b Merge Changeset: 7af04d2d2139 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7af04d2d2139 Added tag jdk8-b111 for changeset 719befd87c7b ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:38:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:38:56 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b111 for changeset af6244ba81b6 Message-ID: <20131010173914.C10AF62F16@hg.openjdk.java.net> Changeset: a0e8fd2464d6 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a0e8fd2464d6 Added tag jdk8-b111 for changeset af6244ba81b6 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:39:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:39:34 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b111 for changeset 75fd3486e584 Message-ID: <20131010173938.11B8A62F17@hg.openjdk.java.net> Changeset: fc2b6885e60e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fc2b6885e60e Added tag jdk8-b111 for changeset 75fd3486e584 ! .hgtags From gerard.ziemski at oracle.com Thu Oct 10 12:14:37 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 10 Oct 2013 14:14:37 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory Message-ID: <5256FC9D.8060202@oracle.com> Please review this fix that implements os::Bsd:available_memory() Description: This is a simple change - we use a similar implementation that Apple itself uses (see http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) to implement BSD (Apple platform only) implementation for finding out available (free) memory. Testing: Passed JPRT, vm quicklooks References: http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8025942 cheers From morris.meyer at oracle.com Thu Oct 10 12:35:19 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 10 Oct 2013 15:35:19 -0400 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <5256FC9D.8060202@oracle.com> References: <5256FC9D.8060202@oracle.com> Message-ID: <52570177.5070904@oracle.com> Looks good. Not a reviewer. --mm On 10/10/13 3:14 PM, Gerard Ziemski wrote: > Please review this fix that implements os::Bsd:available_memory() > > Description: > > This is a simple change - we use a similar implementation that Apple > itself uses (see > http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) > to implement BSD (Apple platform only) implementation for finding out > available (free) memory. > > > Testing: > > Passed JPRT, vm quicklooks > > > References: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8025942 > > > cheers > From dmitry.samersoff at oracle.com Thu Oct 10 12:36:18 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Oct 2013 23:36:18 +0400 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <5256FC9D.8060202@oracle.com> References: <5256FC9D.8060202@oracle.com> Message-ID: <525701B2.8030603@oracle.com> Gerard, Please move uint64_t available = physical_memory() >> 2; under #else Besides that looks good for me -Dmitry On 2013-10-10 23:14, Gerard Ziemski wrote: > Please review this fix that implements os::Bsd:available_memory() > > Description: > > This is a simple change - we use a similar implementation that Apple > itself uses (see > http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) > to implement BSD (Apple platform only) implementation for finding out > available (free) memory. > > > Testing: > > Passed JPRT, vm quicklooks > > > References: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8025942 > > > cheers > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From gerard.ziemski at oracle.com Thu Oct 10 12:50:24 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 10 Oct 2013 14:50:24 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <525701B2.8030603@oracle.com> References: <5256FC9D.8060202@oracle.com> <525701B2.8030603@oracle.com> Message-ID: <52570500.7070401@oracle.com> hi Dmitry, Why should we move it into '#else' clause? host_statistics64 can fail in theory, so from code coverage point of view it's useful to have the variable initialized to some 'sane' value, otherwise we would need to initialize it something and then we need to answer the question - what should it be initialized to? And in that case a reasonable value would be what it currently is. cheers On 10/10/2013 2:36 PM, Dmitry Samersoff wrote: > Gerard, > > Please move > > uint64_t available = physical_memory() >> 2; > > under #else > > Besides that looks good for me > > -Dmitry > > > On 2013-10-10 23:14, Gerard Ziemski wrote: >> Please review this fix that implements os::Bsd:available_memory() >> >> Description: >> >> This is a simple change - we use a similar implementation that Apple >> itself uses (see >> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >> to implement BSD (Apple platform only) implementation for finding out >> available (free) memory. >> >> >> Testing: >> >> Passed JPRT, vm quicklooks >> >> >> References: >> >> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >> >> https://bugs.openjdk.java.net/browse/JDK-8025942 >> >> >> cheers >> > From dmitry.samersoff at oracle.com Thu Oct 10 12:54:47 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Oct 2013 23:54:47 +0400 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52570500.7070401@oracle.com> References: <5256FC9D.8060202@oracle.com> <525701B2.8030603@oracle.com> <52570500.7070401@oracle.com> Message-ID: <52570607.4070200@oracle.com> Gerard. > host_statistics64 can fail in theory, Agree. You are right. Lets leave it as is. -Dmitry On 2013-10-10 23:50, Gerard Ziemski wrote: > hi Dmitry, > > Why should we move it into '#else' clause? > > host_statistics64 can fail in theory, so from code coverage point of > view it's useful to have the variable initialized to some 'sane' value, > otherwise we would need to initialize it something and then we need to > answer the question - what should it be initialized to? And in that case > a reasonable value would be what it currently is. > > > cheers > > On 10/10/2013 2:36 PM, Dmitry Samersoff wrote: >> Gerard, >> >> Please move >> >> uint64_t available = physical_memory() >> 2; >> >> under #else >> >> Besides that looks good for me >> >> -Dmitry >> >> >> On 2013-10-10 23:14, Gerard Ziemski wrote: >>> Please review this fix that implements os::Bsd:available_memory() >>> >>> Description: >>> >>> This is a simple change - we use a similar implementation that Apple >>> itself uses (see >>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>> >>> to implement BSD (Apple platform only) implementation for finding out >>> available (free) memory. >>> >>> >>> Testing: >>> >>> Passed JPRT, vm quicklooks >>> >>> >>> References: >>> >>> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8025942 >>> >>> >>> cheers >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Thu Oct 10 21:32:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2013 14:32:31 +1000 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <5256FC9D.8060202@oracle.com> References: <5256FC9D.8060202@oracle.com> Message-ID: <52577F5F.8030000@oracle.com> Hi Gerard, On 11/10/2013 5:14 AM, Gerard Ziemski wrote: > Please review this fix that implements os::Bsd:available_memory() > > Description: > > This is a simple change - we use a similar implementation that Apple > itself uses (see > http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) > to implement BSD (Apple platform only) implementation for finding out > available (free) memory. Is host_statistics64 likely to fail? If not then I think we should trap any failures, at least with an assert, so that they are noticed. Otherwise this might fail all the time and we would be none the wiser. Thanks, David > > Testing: > > Passed JPRT, vm quicklooks > > > References: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8025942 > > > cheers > From calvin.cheung at oracle.com Thu Oct 10 22:53:36 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Fri, 11 Oct 2013 05:53:36 +0000 Subject: hg: hsx/hotspot-main/hotspot: 30 new changesets Message-ID: <20131011055459.B4C5162F5E@hg.openjdk.java.net> Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f21415c32ca1 Merge Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6f73bc5df986 Merge Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9855f17334d8 Merge Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ae82c3a781a Merge Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3bf767171ea4 Merge Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4212bfb33d76 Merge Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9c63ad02c0a4 Merge Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.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/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ced68a57cdbd Merge Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c01f4910f5f5 Merge From goetz.lindenmaier at sap.com Fri Oct 11 06:34:20 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Oct 2013 13:34:20 +0000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Message-ID: <4295855A5C1DE049A61835A1887419CC0D03E703@DEWDFEMB12A.global.corp.sap> Hi, I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. This is part of the PPC port. http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ For a detailed description see the text in the webrev and bug description. All this basically does is add a field to load and store nodes and change all constructor calls to set this field. So the effect on existing platforms should be very small. Therefore I marked this 'M', although quite some lines of code are touched. Please review and test this change. I'm happy to incorporate your comments and any improvements you propose. Best regards, Goetz. From gerard.ziemski at oracle.com Fri Oct 11 08:26:00 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Oct 2013 10:26:00 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52577F5F.8030000@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> Message-ID: <52581888.2090609@oracle.com> hi David, On 10/10/2013 11:32 PM, David Holmes wrote: > Hi Gerard, > > On 11/10/2013 5:14 AM, Gerard Ziemski wrote: >> Please review this fix that implements os::Bsd:available_memory() >> >> Description: >> >> This is a simple change - we use a similar implementation that Apple >> itself uses (see >> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >> >> to implement BSD (Apple platform only) implementation for finding out >> available (free) memory. > > Is host_statistics64 likely to fail? If not then I think we should > trap any failures, at least with an assert, so that they are noticed. > Otherwise this might fail all the time and we would be none the wiser. I looked at the implementation of host_statistics64 in XNU src and the only reason it will fail is if we pass wrong parameters (such as NULL host). Otherwise, it is guaranteed to return a valid value, so there does not seem to be a need for an assert here. cheers From harold.seigel at oracle.com Fri Oct 11 08:33:11 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 11 Oct 2013 11:33:11 -0400 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52581888.2090609@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> <52581888.2090609@oracle.com> Message-ID: <52581A37.8070205@oracle.com> Hi Gerard, Since host_statistics64 is unlikely to fail, can you add an assert to ensure that we catch the rare case when it fails? Thanks, Harold On 10/11/2013 11:26 AM, Gerard Ziemski wrote: > hi David, > > On 10/10/2013 11:32 PM, David Holmes wrote: >> Hi Gerard, >> >> On 11/10/2013 5:14 AM, Gerard Ziemski wrote: >>> Please review this fix that implements os::Bsd:available_memory() >>> >>> Description: >>> >>> This is a simple change - we use a similar implementation that Apple >>> itself uses (see >>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>> >>> to implement BSD (Apple platform only) implementation for finding out >>> available (free) memory. >> >> Is host_statistics64 likely to fail? If not then I think we should >> trap any failures, at least with an assert, so that they are noticed. >> Otherwise this might fail all the time and we would be none the wiser. > > I looked at the implementation of host_statistics64 in XNU src and the > only reason it will fail is if we pass wrong parameters (such as NULL > host). Otherwise, it is guaranteed to return a valid value, so there > does not seem to be a need for an assert here. > > > cheers From gerard.ziemski at oracle.com Fri Oct 11 08:47:42 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Oct 2013 10:47:42 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52581A37.8070205@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> <52581888.2090609@oracle.com> <52581A37.8070205@oracle.com> Message-ID: <52581D9E.4080405@oracle.com> hi Harold, I don't think that's necessary - the call will fail in 2 cases: 1. null host 2. wrong attribute size Re 1. we use mach_host_self() to get the host - if that were to fail, we'd have failed long before here. Re 2. the XNU implementation of the call checks that attribute size is set to HOST_VM_INFO64_COUNT, which is what we use so in my opinion no assert is needed, and adding it might in fact muddle the waters as any future reader of the code might very well think that it's likely to fail. cheers On 10/11/2013 10:33 AM, harold seigel wrote: > Hi Gerard, > > Since host_statistics64 is unlikely to fail, can you add an assert to > ensure that we catch the rare case when it fails? > > Thanks, Harold > > On 10/11/2013 11:26 AM, Gerard Ziemski wrote: >> hi David, >> >> On 10/10/2013 11:32 PM, David Holmes wrote: >>> Hi Gerard, >>> >>> On 11/10/2013 5:14 AM, Gerard Ziemski wrote: >>>> Please review this fix that implements os::Bsd:available_memory() >>>> >>>> Description: >>>> >>>> This is a simple change - we use a similar implementation that Apple >>>> itself uses (see >>>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>>> >>>> to implement BSD (Apple platform only) implementation for finding out >>>> available (free) memory. >>> >>> Is host_statistics64 likely to fail? If not then I think we should >>> trap any failures, at least with an assert, so that they are >>> noticed. Otherwise this might fail all the time and we would be none >>> the wiser. >> >> I looked at the implementation of host_statistics64 in XNU src and >> the only reason it will fail is if we pass wrong parameters (such as >> NULL host). Otherwise, it is guaranteed to return a valid value, so >> there does not seem to be a need for an assert here. >> >> >> cheers > > > From daniel.daugherty at oracle.com Fri Oct 11 08:52:46 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 09:52:46 -0600 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52581D9E.4080405@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> <52581888.2090609@oracle.com> <52581A37.8070205@oracle.com> <52581D9E.4080405@oracle.com> Message-ID: <52581ECE.5020708@oracle.com> Actually an 'assert' is exactly what you want in this case. The call shouldn't fail unless we have a coding error so in the event that we introduce a code error in the future, the assert will fire. Dan On 10/11/13 9:47 AM, Gerard Ziemski wrote: > hi Harold, > > I don't think that's necessary - the call will fail in 2 cases: > > 1. null host > 2. wrong attribute size > > Re 1. we use mach_host_self() to get the host - if that were to fail, > we'd have failed long before here. > Re 2. the XNU implementation of the call checks that attribute size is > set to HOST_VM_INFO64_COUNT, which is what we use > > so in my opinion no assert is needed, and adding it might in fact > muddle the waters as any future reader of the code might very well > think that it's likely to fail. > > > cheers > > On 10/11/2013 10:33 AM, harold seigel wrote: >> Hi Gerard, >> >> Since host_statistics64 is unlikely to fail, can you add an assert to >> ensure that we catch the rare case when it fails? >> >> Thanks, Harold >> >> On 10/11/2013 11:26 AM, Gerard Ziemski wrote: >>> hi David, >>> >>> On 10/10/2013 11:32 PM, David Holmes wrote: >>>> Hi Gerard, >>>> >>>> On 11/10/2013 5:14 AM, Gerard Ziemski wrote: >>>>> Please review this fix that implements os::Bsd:available_memory() >>>>> >>>>> Description: >>>>> >>>>> This is a simple change - we use a similar implementation that Apple >>>>> itself uses (see >>>>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>>>> >>>>> to implement BSD (Apple platform only) implementation for finding out >>>>> available (free) memory. >>>> >>>> Is host_statistics64 likely to fail? If not then I think we should >>>> trap any failures, at least with an assert, so that they are >>>> noticed. Otherwise this might fail all the time and we would be >>>> none the wiser. >>> >>> I looked at the implementation of host_statistics64 in XNU src and >>> the only reason it will fail is if we pass wrong parameters (such as >>> NULL host). Otherwise, it is guaranteed to return a valid value, so >>> there does not seem to be a need for an assert here. >>> >>> >>> cheers >> >> >> > From coleen.phillimore at oracle.com Fri Oct 11 08:53:38 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Oct 2013 11:53:38 -0400 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52581D9E.4080405@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> <52581888.2090609@oracle.com> <52581A37.8070205@oracle.com> <52581D9E.4080405@oracle.com> Message-ID: <52581F02.4050105@oracle.com> On 10/11/2013 11:47 AM, Gerard Ziemski wrote: > hi Harold, > > I don't think that's necessary - the call will fail in 2 cases: > > 1. null host > 2. wrong attribute size > > Re 1. we use mach_host_self() to get the host - if that were to fail, > we'd have failed long before here. > Re 2. the XNU implementation of the call checks that attribute size is > set to HOST_VM_INFO64_COUNT, which is what we use > > so in my opinion no assert is needed, and adding it might in fact > muddle the waters as any future reader of the code might very well > think that it's likely to fail. If you add an assert with the message that should provide executable documentation that these conditions are true. Coleen > > > cheers > > On 10/11/2013 10:33 AM, harold seigel wrote: >> Hi Gerard, >> >> Since host_statistics64 is unlikely to fail, can you add an assert to >> ensure that we catch the rare case when it fails? >> >> Thanks, Harold >> >> On 10/11/2013 11:26 AM, Gerard Ziemski wrote: >>> hi David, >>> >>> On 10/10/2013 11:32 PM, David Holmes wrote: >>>> Hi Gerard, >>>> >>>> On 11/10/2013 5:14 AM, Gerard Ziemski wrote: >>>>> Please review this fix that implements os::Bsd:available_memory() >>>>> >>>>> Description: >>>>> >>>>> This is a simple change - we use a similar implementation that Apple >>>>> itself uses (see >>>>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>>>> >>>>> to implement BSD (Apple platform only) implementation for finding out >>>>> available (free) memory. >>>> >>>> Is host_statistics64 likely to fail? If not then I think we should >>>> trap any failures, at least with an assert, so that they are >>>> noticed. Otherwise this might fail all the time and we would be >>>> none the wiser. >>> >>> I looked at the implementation of host_statistics64 in XNU src and >>> the only reason it will fail is if we pass wrong parameters (such as >>> NULL host). Otherwise, it is guaranteed to return a valid value, so >>> there does not seem to be a need for an assert here. >>> >>> >>> cheers >> >> >> > From gerard.ziemski at oracle.com Fri Oct 11 08:56:02 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Oct 2013 10:56:02 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52581ECE.5020708@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> <52581888.2090609@oracle.com> <52581A37.8070205@oracle.com> <52581D9E.4080405@oracle.com> <52581ECE.5020708@oracle.com> Message-ID: <52581F92.2010701@oracle.com> A single run of the code will verify that it's coded correctly. An assert would be needed if the conditions were likely to change during runtime. If we were, for example, dynamically calculating the attribute size, then things might go wrong, but that's not the case here - we use a constant. cheers On 10/11/2013 10:52 AM, Daniel D. Daugherty wrote: > Actually an 'assert' is exactly what you want in this case. > The call shouldn't fail unless we have a coding error so in the > event that we introduce a code error in the future, the assert > will fire. > > Dan > > > On 10/11/13 9:47 AM, Gerard Ziemski wrote: >> hi Harold, >> >> I don't think that's necessary - the call will fail in 2 cases: >> >> 1. null host >> 2. wrong attribute size >> >> Re 1. we use mach_host_self() to get the host - if that were to fail, >> we'd have failed long before here. >> Re 2. the XNU implementation of the call checks that attribute size >> is set to HOST_VM_INFO64_COUNT, which is what we use >> >> so in my opinion no assert is needed, and adding it might in fact >> muddle the waters as any future reader of the code might very well >> think that it's likely to fail. >> >> >> cheers >> >> On 10/11/2013 10:33 AM, harold seigel wrote: >>> Hi Gerard, >>> >>> Since host_statistics64 is unlikely to fail, can you add an assert >>> to ensure that we catch the rare case when it fails? >>> >>> Thanks, Harold >>> >>> On 10/11/2013 11:26 AM, Gerard Ziemski wrote: >>>> hi David, >>>> >>>> On 10/10/2013 11:32 PM, David Holmes wrote: >>>>> Hi Gerard, >>>>> >>>>> On 11/10/2013 5:14 AM, Gerard Ziemski wrote: >>>>>> Please review this fix that implements os::Bsd:available_memory() >>>>>> >>>>>> Description: >>>>>> >>>>>> This is a simple change - we use a similar implementation that Apple >>>>>> itself uses (see >>>>>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>>>>> >>>>>> to implement BSD (Apple platform only) implementation for finding >>>>>> out >>>>>> available (free) memory. >>>>> >>>>> Is host_statistics64 likely to fail? If not then I think we should >>>>> trap any failures, at least with an assert, so that they are >>>>> noticed. Otherwise this might fail all the time and we would be >>>>> none the wiser. >>>> >>>> I looked at the implementation of host_statistics64 in XNU src and >>>> the only reason it will fail is if we pass wrong parameters (such >>>> as NULL host). Otherwise, it is guaranteed to return a valid value, >>>> so there does not seem to be a need for an assert here. >>>> >>>> >>>> cheers >>> >>> >>> >> > > From gerard.ziemski at oracle.com Fri Oct 11 09:16:07 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Oct 2013 11:16:07 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52581F02.4050105@oracle.com> References: <5256FC9D.8060202@oracle.com> <52577F5F.8030000@oracle.com> <52581888.2090609@oracle.com> <52581A37.8070205@oracle.com> <52581D9E.4080405@oracle.com> <52581F02.4050105@oracle.com> Message-ID: <52582447.9030404@oracle.com> On 10/11/2013 10:53 AM, Coleen Phillimore wrote: > On 10/11/2013 11:47 AM, Gerard Ziemski wrote: >> hi Harold, >> >> I don't think that's necessary - the call will fail in 2 cases: >> >> 1. null host >> 2. wrong attribute size >> >> Re 1. we use mach_host_self() to get the host - if that were to fail, >> we'd have failed long before here. >> Re 2. the XNU implementation of the call checks that attribute size >> is set to HOST_VM_INFO64_COUNT, which is what we use >> >> so in my opinion no assert is needed, and adding it might in fact >> muddle the waters as any future reader of the code might very well >> think that it's likely to fail. > > If you add an assert with the message that should provide executable > documentation that these conditions are true. We're going to use a runtime code to document a proper usage of an API? Are we then saying we need to document system API calls in such way? Because if we do, wouldn't we need to do this for every single API call? I remain unconvinced that host_statistics64() requires an assert, but since the team seems to feel strongly about this, I will add it. cheers From daniel.daugherty at oracle.com Fri Oct 11 09:44:49 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 10:44:49 -0600 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <5256FC9D.8060202@oracle.com> References: <5256FC9D.8060202@oracle.com> Message-ID: <52582B01.4050800@oracle.com> > http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ src/os/bsd/vm/os_bsd.cpp nit line 166 kern_return_t kerr = host_statistics64(mach_host_self(), HOST_VM_INFO64, (host_info64_t)&vmstat, &count); This line is longer than 80 chars. Please reformat it to something like: 166 kern_return_t kerr = host_statistics64(mach_host_self(), HOST_VM_INFO64, (host_info64_t)&vmstat, &count); Thumbs up. Dan On 10/10/13 1:14 PM, Gerard Ziemski wrote: > Please review this fix that implements os::Bsd:available_memory() > > Description: > > This is a simple change - we use a similar implementation that Apple > itself uses (see > http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) > to implement BSD (Apple platform only) implementation for finding out > available (free) memory. > > > Testing: > > Passed JPRT, vm quicklooks > > > References: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8025942 > > > cheers > > > From daniel.daugherty at oracle.com Fri Oct 11 09:46:33 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 10:46:33 -0600 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52582B01.4050800@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> Message-ID: <52582B69.8060709@oracle.com> My e-mail client reformatted the line... However, there are plenty of examples of HotSpot's style for breaking function calls when they are longer than 80 chars... Dan On 10/11/13 10:44 AM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ > > > src/os/bsd/vm/os_bsd.cpp > nit line 166 kern_return_t kerr = > host_statistics64(mach_host_self(), HOST_VM_INFO64, > (host_info64_t)&vmstat, &count); > > This line is longer than 80 chars. Please reformat it > to something like: > > 166 kern_return_t kerr = host_statistics64(mach_host_self(), > HOST_VM_INFO64, > (host_info64_t)&vmstat, &count); > > Thumbs up. > > Dan > > > On 10/10/13 1:14 PM, Gerard Ziemski wrote: >> Please review this fix that implements os::Bsd:available_memory() >> >> Description: >> >> This is a simple change - we use a similar implementation that Apple >> itself uses (see >> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >> to implement BSD (Apple platform only) implementation for finding out >> available (free) memory. >> >> >> Testing: >> >> Passed JPRT, vm quicklooks >> >> >> References: >> >> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >> >> https://bugs.openjdk.java.net/browse/JDK-8025942 >> >> >> cheers >> >> >> > From gerard.ziemski at oracle.com Fri Oct 11 10:20:35 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Oct 2013 12:20:35 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52582B69.8060709@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> <52582B69.8060709@oracle.com> Message-ID: <52583363.8050004@oracle.com> OK, I will do that, but do we seriously still care about 80 character limit? cheers On 10/11/2013 11:46 AM, Daniel D. Daugherty wrote: > My e-mail client reformatted the line... > > However, there are plenty of examples of HotSpot's > style for breaking function calls when they are longer > than 80 chars... > > Dan > > > On 10/11/13 10:44 AM, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >> >> >> src/os/bsd/vm/os_bsd.cpp >> nit line 166 kern_return_t kerr = >> host_statistics64(mach_host_self(), HOST_VM_INFO64, >> (host_info64_t)&vmstat, &count); >> >> This line is longer than 80 chars. Please reformat it >> to something like: >> >> 166 kern_return_t kerr = host_statistics64(mach_host_self(), >> HOST_VM_INFO64, >> (host_info64_t)&vmstat, &count); >> >> Thumbs up. >> >> Dan >> >> >> On 10/10/13 1:14 PM, Gerard Ziemski wrote: >>> Please review this fix that implements os::Bsd:available_memory() >>> >>> Description: >>> >>> This is a simple change - we use a similar implementation that Apple >>> itself uses (see >>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>> to implement BSD (Apple platform only) implementation for finding >>> out available (free) memory. >>> >>> >>> Testing: >>> >>> Passed JPRT, vm quicklooks >>> >>> >>> References: >>> >>> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8025942 >>> >>> >>> cheers >>> >>> >>> >> > > > From daniel.daugherty at oracle.com Fri Oct 11 10:52:26 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 11:52:26 -0600 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52583363.8050004@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> <52582B69.8060709@oracle.com> <52583363.8050004@oracle.com> Message-ID: <52583ADA.2050205@oracle.com> On 10/11/13 11:20 AM, Gerard Ziemski wrote: > OK, I will do that, but do we seriously still care about 80 character > limit? Yes. At least for Runtime and Serviceability code. Don't really know about the GC and Compiler teams. Dan > > > cheers > > On 10/11/2013 11:46 AM, Daniel D. Daugherty wrote: >> My e-mail client reformatted the line... >> >> However, there are plenty of examples of HotSpot's >> style for breaking function calls when they are longer >> than 80 chars... >> >> Dan >> >> >> On 10/11/13 10:44 AM, Daniel D. Daugherty wrote: >>> > >>> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >>> >>> >>> src/os/bsd/vm/os_bsd.cpp >>> nit line 166 kern_return_t kerr = >>> host_statistics64(mach_host_self(), HOST_VM_INFO64, >>> (host_info64_t)&vmstat, &count); >>> >>> This line is longer than 80 chars. Please reformat it >>> to something like: >>> >>> 166 kern_return_t kerr = host_statistics64(mach_host_self(), >>> HOST_VM_INFO64, >>> (host_info64_t)&vmstat, &count); >>> >>> Thumbs up. >>> >>> Dan >>> >>> >>> On 10/10/13 1:14 PM, Gerard Ziemski wrote: >>>> Please review this fix that implements os::Bsd:available_memory() >>>> >>>> Description: >>>> >>>> This is a simple change - we use a similar implementation that >>>> Apple itself uses (see >>>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) >>>> to implement BSD (Apple platform only) implementation for finding >>>> out available (free) memory. >>>> >>>> >>>> Testing: >>>> >>>> Passed JPRT, vm quicklooks >>>> >>>> >>>> References: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/sponsorship/gziemski/JDK-8025942/webrev.01/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8025942 >>>> >>>> >>>> cheers >>>> >>>> >>>> >>> >> >> >> > From gerard.ziemski at oracle.com Fri Oct 11 11:26:16 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Oct 2013 13:26:16 -0500 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52583ADA.2050205@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> <52582B69.8060709@oracle.com> <52583363.8050004@oracle.com> <52583ADA.2050205@oracle.com> Message-ID: <525842C8.90103@oracle.com> For completeness, may I why do we care and where does it say we should? cheers On 10/11/2013 12:52 PM, Daniel D. Daugherty wrote: > On 10/11/13 11:20 AM, Gerard Ziemski wrote: >> OK, I will do that, but do we seriously still care about 80 character >> limit? > > Yes. At least for Runtime and Serviceability code. Don't really > know about the GC and Compiler teams. > > Dan From daniel.daugherty at oracle.com Fri Oct 11 11:28:53 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 12:28:53 -0600 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <525842C8.90103@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> <52582B69.8060709@oracle.com> <52583363.8050004@oracle.com> <52583ADA.2050205@oracle.com> <525842C8.90103@oracle.com> Message-ID: <52584365.1000705@oracle.com> John Rose is the 'keeper' of the HotSpot coding guide. As for why we care, personally, I still use 'vi' in an 80 column wide Xterm window... well several of them tiled across my MacBookPro 17" screen... Dan On 10/11/13 12:26 PM, Gerard Ziemski wrote: > For completeness, may I why do we care and where does it say we should? > > > cheers > > On 10/11/2013 12:52 PM, Daniel D. Daugherty wrote: >> On 10/11/13 11:20 AM, Gerard Ziemski wrote: >>> OK, I will do that, but do we seriously still care about 80 >>> character limit? >> >> Yes. At least for Runtime and Serviceability code. Don't really >> know about the GC and Compiler teams. >> >> Dan > From john.coomes at oracle.com Fri Oct 11 11:28:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Oct 2013 18:28:03 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20131011182840.C7D7362F92@hg.openjdk.java.net> Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp From kmcguigan at twitter.com Fri Oct 11 11:33:11 2013 From: kmcguigan at twitter.com (Keith McGuigan) Date: Fri, 11 Oct 2013 14:33:11 -0400 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52584365.1000705@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> <52582B69.8060709@oracle.com> <52583363.8050004@oracle.com> <52583ADA.2050205@oracle.com> <525842C8.90103@oracle.com> <52584365.1000705@oracle.com> Message-ID: Ditto. On Fri, Oct 11, 2013 at 2:28 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > John Rose is the 'keeper' of the HotSpot coding guide. > > As for why we care, personally, I still use 'vi' in an 80 column > wide Xterm window... well several of them tiled across my MacBookPro > 17" screen... > > Dan > > > On 10/11/13 12:26 PM, Gerard Ziemski wrote: > >> For completeness, may I why do we care and where does it say we should? >> >> >> cheers >> >> On 10/11/2013 12:52 PM, Daniel D. Daugherty wrote: >> >>> On 10/11/13 11:20 AM, Gerard Ziemski wrote: >>> >>>> OK, I will do that, but do we seriously still care about 80 character >>>> limit? >>>> >>> >>> Yes. At least for Runtime and Serviceability code. Don't really >>> know about the GC and Compiler teams. >>> >>> Dan >>> >> >> > From gnu.andrew at redhat.com Fri Oct 11 13:32:20 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Oct 2013 16:32:20 -0400 (EDT) Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <524DC82C.5000800@oracle.com> References: <524DC82C.5000800@oracle.com> Message-ID: <864099904.5642876.1381523540522.JavaMail.root@redhat.com> ----- Original Message ----- > Please review this change to turn off transparent huge pages by default. > > http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ > > 8024838: Significant slowdown due to transparent huge pages > Summary: Don't turn on transparent huge pages > (-XX:+UseTransparentHugePages) unless explicitly specified on the > command line. This has the effect that large pages are never turned on > Linux unless the user has explicitly enabled any of the large pages > flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, > -XX:+UseHugeTLBFS, and -XX:+UseSHM. > Reviewed-by: TBD1, TBD2 > > thanks, > StefanK > Can you explain where you see this slowdown? I'm a little worried that this does not seem to have been questioned in this review. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From stefan.karlsson at oracle.com Fri Oct 11 13:51:37 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 11 Oct 2013 22:51:37 +0200 Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <864099904.5642876.1381523540522.JavaMail.root@redhat.com> References: <524DC82C.5000800@oracle.com> <864099904.5642876.1381523540522.JavaMail.root@redhat.com> Message-ID: <525864D9.20803@oracle.com> On 10/11/13 10:32 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Please review this change to turn off transparent huge pages by default. >> >> http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ >> >> 8024838: Significant slowdown due to transparent huge pages >> Summary: Don't turn on transparent huge pages >> (-XX:+UseTransparentHugePages) unless explicitly specified on the >> command line. This has the effect that large pages are never turned on >> Linux unless the user has explicitly enabled any of the large pages >> flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, >> -XX:+UseHugeTLBFS, and -XX:+UseSHM. >> Reviewed-by: TBD1, TBD2 >> >> thanks, >> StefanK >> > Can you explain where you see this slowdown? One of the issues are described in the bug: https://bugs.openjdk.java.net/browse/JDK-8024838 There's another issues we're Nashorn runs 10% slower with CompressedOops turned on, most likely due to THP in the Compressed Class Space. That bug is marked Confidential, so I can't give you a link. =( Another issue is the extra memory usage for small work loads. That bug is, apparently, also marked Confidential. See also: https://blogs.oracle.com/linux/entry/performance_issues_with_transparent_huge > I'm a little worried that > this does not seem to have been questioned in this review. Turning transparent huge pages on by default was done prematurely. If we do more performance evaluations in the future, this decision could be reevaluated. If anyone still wants large pages they are free to use either of: -XX:+UseTransparentHugePages -XX:+UseHugeTLBFS -XX:+UseSHM thanks, StefanK > > Thanks, From gnu.andrew at redhat.com Fri Oct 11 15:26:17 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Oct 2013 18:26:17 -0400 (EDT) Subject: Review request: (turn off transparent huge pages) 8024838: Significant slowdown due to transparent huge pages In-Reply-To: <525864D9.20803@oracle.com> References: <524DC82C.5000800@oracle.com> <864099904.5642876.1381523540522.JavaMail.root@redhat.com> <525864D9.20803@oracle.com> Message-ID: <1989839091.5664903.1381530377212.JavaMail.root@redhat.com> ----- Original Message ----- > On 10/11/13 10:32 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Please review this change to turn off transparent huge pages by default. > >> > >> http://cr.openjdk.java.net/~stefank/8024838/webrev.00/ > >> > >> 8024838: Significant slowdown due to transparent huge pages > >> Summary: Don't turn on transparent huge pages > >> (-XX:+UseTransparentHugePages) unless explicitly specified on the > >> command line. This has the effect that large pages are never turned on > >> Linux unless the user has explicitly enabled any of the large pages > >> flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, > >> -XX:+UseHugeTLBFS, and -XX:+UseSHM. > >> Reviewed-by: TBD1, TBD2 > >> > >> thanks, > >> StefanK > >> > > Can you explain where you see this slowdown? > > One of the issues are described in the bug: > https://bugs.openjdk.java.net/browse/JDK-8024838 > > There's another issues we're Nashorn runs 10% slower with CompressedOops > turned on, most likely due to THP in the Compressed Class Space. That > bug is marked Confidential, so I can't give you a link. =( > > Another issue is the extra memory usage for small work loads. That bug > is, apparently, also marked Confidential. > > See also: > https://blogs.oracle.com/linux/entry/performance_issues_with_transparent_huge > > > I'm a little worried that > > this does not seem to have been questioned in this review. > > Turning transparent huge pages on by default was done prematurely. If we > do more performance evaluations in the future, this decision could be > reevaluated. > > If anyone still wants large pages they are free to use either of: > -XX:+UseTransparentHugePages > -XX:+UseHugeTLBFS > -XX:+UseSHM > > thanks, > StefanK > > > > Thanks, > > Thanks for the explanation. I'm just anticipating that we're inevitably going to get asked about this when it works its way through into a HotSpot in OpenJDK 7 some time from now. The original bug just made it sound like it was one developer's machine, which seemed a bit curious. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From christian.thalinger at oracle.com Fri Oct 11 16:45:01 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Oct 2013 16:45:01 -0700 Subject: RFR(S): 8025942: Implement os::Bsd:available_memory In-Reply-To: <52584365.1000705@oracle.com> References: <5256FC9D.8060202@oracle.com> <52582B01.4050800@oracle.com> <52582B69.8060709@oracle.com> <52583363.8050004@oracle.com> <52583ADA.2050205@oracle.com> <525842C8.90103@oracle.com> <52584365.1000705@oracle.com> Message-ID: On Oct 11, 2013, at 11:28 AM, Daniel D. Daugherty wrote: > John Rose is the 'keeper' of the HotSpot coding guide. > > As for why we care, personally, I still use 'vi' in an 80 column > wide Xterm window? Be bold and make it wider :-) > well several of them tiled across my MacBookPro > 17" screen... > > Dan > > > On 10/11/13 12:26 PM, Gerard Ziemski wrote: >> For completeness, may I why do we care and where does it say we should? >> >> >> cheers >> >> On 10/11/2013 12:52 PM, Daniel D. Daugherty wrote: >>> On 10/11/13 11:20 AM, Gerard Ziemski wrote: >>>> OK, I will do that, but do we seriously still care about 80 character limit? >>> >>> Yes. At least for Runtime and Serviceability code. Don't really >>> know about the GC and Compiler teams. >>> >>> Dan >> > From john.coomes at oracle.com Fri Oct 11 16:49:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Oct 2013 23:49:10 +0000 Subject: hg: hsx/hsx25/hotspot: 45 new changesets Message-ID: <20131011235206.1B18762FB6@hg.openjdk.java.net> Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f21415c32ca1 Merge Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6f73bc5df986 Merge Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9855f17334d8 Merge Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ae82c3a781a Merge Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3bf767171ea4 Merge Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4212bfb33d76 Merge Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9c63ad02c0a4 Merge Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.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/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ced68a57cdbd Merge Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c01f4910f5f5 Merge Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags From john.coomes at oracle.com Fri Oct 11 21:11:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 12 Oct 2013 04:11:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131012041203.20E1D62FCC@hg.openjdk.java.net> Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version From francis.andre.kampbell at orange.fr Sun Oct 13 07:05:39 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sun, 13 Oct 2013 16:05:39 +0200 Subject: [SPAM]Re: Review request for JDK-8014933: Remove JVM_SetProtectionDomain from hotspot In-Reply-To: <51DAFDF6.7080306@oracle.com> References: <51D1F51C.5050607@oracle.com> <51D1F928.9020103@oracle.com> <51DAFDF6.7080306@oracle.com> Message-ID: <525AA8B3.303@orange.fr> Hi Eric I am using the jdk7u40 for building the jdk8/hotspot on WXP/Cygwin/VS2010 and got this exception when running hotspot.exe The entry point _JVM_SetProtectionDomain at 12 cannot be found in the dynamic link library jmv.dll Can your changeset be backported to the 7u40 release? Francis Le 08/07/2013 19:59, Eric McCorkle a ?crit : > Changes have been incorporated. New webrev: > http://cr.openjdk.java.net/~emc/8014933/ > > I still need a second reviewer for this. > > On 07/01/13 17:48, Coleen Phillimore wrote: >> Hi Eric, >> >> This looks good -except can you move >> java_lang_Class::set_protection_domain into the private part of >> java_lang_Class with set_init_lock? The only caller is from within >> java_lang_Class class now. >> >> thanks, >> Coleen >> >> On 07/01/2013 05:31 PM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review the following patch, which removes the deprecated JNI call >>> JVM_SetProtectionDomain from hotspot. >>> >>> The corresponding patch, which removes use of JVM_SetProtectionDomain >>> was committed a while back to jdk8/tl, and was integrated into >>> hsx/hotspot-rt late last week. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8014933/ >>> >>> Thanks, >>> Eric From david.holmes at oracle.com Sun Oct 13 19:20:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Oct 2013 12:20:26 +1000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D03E703@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D03E703@DEWDFEMB12A.global.corp.sap> Message-ID: <525B54EA.9020006@oracle.com> Hi Goetz, As I wrote in the bug report: "This needs to be considered very carefully. The only time C2 needs to be concerned with memory ordering is for Java volatiles and in that case there are both atomicity and ordering issues to consider. In addition we have to ensure that the low level load.acq and st.rel instructions provide the correct semantics to implement volatile variables. Rather than change the kind of nodes I would have expected that the actual code generation would combine the load+membarAcquire nodes into the relevant ld.acq instruction if applicable! Also see JDK-7143664." This is up to the compiler guys of course. Cheers, David On 11/10/2013 11:34 PM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. > This is part of the PPC port. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > For a detailed description see the text in the webrev and bug description. > > All this basically does is add a field to load and store nodes and > change all constructor calls to set this field. So the effect on > existing platforms should be very small. Therefore I marked this > 'M', although quite some lines of code are touched. > > Please review and test this change. > I'm happy to incorporate your comments and any improvements > you propose. > > Best regards, > Goetz. > > > > From goetz.lindenmaier at sap.com Mon Oct 14 00:43:22 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Oct 2013 07:43:22 +0000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <525B54EA.9020006@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D03E703@DEWDFEMB12A.global.corp.sap> <525B54EA.9020006@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D04047A@DEWDFEMB12A.global.corp.sap> Hi David, As for all changes in the PPC port, I don't intend to change anything on your platforms. To our understanding, the low level operations fulfill the requirements. Also, we are using this now for around 6 years on ia64 and ppc. It performs measurable better, and did not raise problems. Matching the nodes together is hard, because matching operations having memory inputs isn't supported, as I understand. I assume this would require changes to the matcher that are more likely to affect other platforms than adding a field to nodes. But as you mention in 7143664, we also find it hard to generate optimal code with the given orderAccess implementations. (Both in the compiler and the runtime code.) To me, it seems to be very hard to find a common, optimal scheme as the instructions offered on the different processors have different semantics. E.g., MemBarAcquire in the compiler is used after Loads, after Cmpxchg, and for Unsafe.acquire. On some platforms, cmpxchg orders memory, on others not, so we need to issue different member instructions after cmpxchg and loads. This is not reflected in the IR. But this is not scope of this change. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 14. Oktober 2013 04:20 To: Lindenmaier, Goetz Cc: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Hi Goetz, As I wrote in the bug report: "This needs to be considered very carefully. The only time C2 needs to be concerned with memory ordering is for Java volatiles and in that case there are both atomicity and ordering issues to consider. In addition we have to ensure that the low level load.acq and st.rel instructions provide the correct semantics to implement volatile variables. Rather than change the kind of nodes I would have expected that the actual code generation would combine the load+membarAcquire nodes into the relevant ld.acq instruction if applicable! Also see JDK-7143664." This is up to the compiler guys of course. Cheers, David On 11/10/2013 11:34 PM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. > This is part of the PPC port. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > For a detailed description see the text in the webrev and bug description. > > All this basically does is add a field to load and store nodes and > change all constructor calls to set this field. So the effect on > existing platforms should be very small. Therefore I marked this > 'M', although quite some lines of code are touched. > > Please review and test this change. > I'm happy to incorporate your comments and any improvements > you propose. > > Best regards, > Goetz. > > > > From erik.joelsson at oracle.com Mon Oct 14 02:25:41 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Oct 2013 11:25:41 +0200 Subject: RFR: JDK-8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Message-ID: <525BB895.3020906@oracle.com> Please review the following changes, correcting the conditions for when to build certain parts of the servicability features. Instead of guarding them with the OPENJDK variable, they need to be conditioned on the existence of the source itself. In hotspot, this only fails on Windows. The linux makefiles already check on the existence of the source rather than if it's an OPENJDK build. This change makes windows do the same. http://cr.openjdk.java.net/~erikj/8019540/webrev.hotspot.01/ In JDK, it fails on all platforms. There is already a configure variable, ENABLE_JFR, that seems to be set correctly for this case. http://cr.openjdk.java.net/~erikj/8019540/webrev.jdk.01/ I will need a sponsor to push this to hotspot if it passes review. /Erik From staffan.larsen at oracle.com Mon Oct 14 02:59:51 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 11:59:51 +0200 Subject: RFR: JDK-8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. In-Reply-To: <525BB895.3020906@oracle.com> References: <525BB895.3020906@oracle.com> Message-ID: Looks good! Of course, the proof is in building it. I can sponsor the hotspot fix. Thanks, /Staffan On 14 okt 2013, at 11:25, Erik Joelsson wrote: > Please review the following changes, correcting the conditions for when to build certain parts of the servicability features. Instead of guarding them with the OPENJDK variable, they need to be conditioned on the existence of the source itself. > > In hotspot, this only fails on Windows. The linux makefiles already check on the existence of the source rather than if it's an OPENJDK build. This change makes windows do the same. > > http://cr.openjdk.java.net/~erikj/8019540/webrev.hotspot.01/ > > In JDK, it fails on all platforms. There is already a configure variable, ENABLE_JFR, that seems to be set correctly for this case. > > http://cr.openjdk.java.net/~erikj/8019540/webrev.jdk.01/ > > I will need a sponsor to push this to hotspot if it passes review. > > /Erik From stefan.karlsson at oracle.com Mon Oct 14 04:58:31 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 14 Oct 2013 13:58:31 +0200 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment Message-ID: <525BDC67.1040902@oracle.com> Please, review these two patches to remove some of the wastages introduced in the metaspace. 8026391: The Metachunk header wastes memory http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8026391 There are a couple of fields in Metachunk that store already known information, like the beginning and the end of the Metachunk. I replaced those fields with code instead. To make this easier, I extracted some duplicated code in Metablock and Metachunk into a super class named Metamem. The extracted code is purely needed to allow these objects to be placed on the FreeList and in the BinaryTreeDictionary. 8026392: Metachunks and Metablocks are using a too large alignment http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8026392 The metaspace code was using ARENA_ALIGN to align the Metablocks and Metachunk header. This forced all allocations of metadata to be 16 bytes aligned. This patch patch changes the restriction to be 8 bytes instead, since that's the restriction needed for 64 bit types like long, double, pointers and klass pointers, Testing: Added unit test for Metachunk. JPRT (before splitting of the patches) thanks, StefanK From jon.masamitsu at oracle.com Mon Oct 14 13:40:00 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 14 Oct 2013 13:40:00 -0700 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525BDC67.1040902@oracle.com> References: <525BDC67.1040902@oracle.com> Message-ID: <525C56A0.3000408@oracle.com> Comments only on the first patch. Looks good. Couple of questions. Why the change from _is_free to _is_marked_free? From 58 bool _is_free; to 105 DEBUG_ONLY(bool _is_marked_free;) Is it to specifically distinguish it from the FreeChunk is_free()? The "marked" in the name feels a little like GC when it isn't GC related. Would "_is_tagged_free" make sense? Did you consider changing the file names from Metachunk.* to Metamem.*? The file contains the classes Metamem, Metablock, and Metachunk. It sees more natural to me to have the file named after the more general Metamem class. Then all the classes in the file are Metamem (or derived from), yes? Jon On 10/14/13 4:58 AM, Stefan Karlsson wrote: > Please, review these two patches to remove some of the wastages > introduced in the metaspace. > > > 8026391: The Metachunk header wastes memory > http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8026391 > > There are a couple of fields in Metachunk that store already known > information, like the beginning and the end of the Metachunk. I > replaced those fields with code instead. > > To make this easier, I extracted some duplicated code in Metablock and > Metachunk into a super class named Metamem. The extracted code is > purely needed to allow these objects to be placed on the FreeList and > in the BinaryTreeDictionary. > > > 8026392: Metachunks and Metablocks are using a too large alignment > http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8026392 > > The metaspace code was using ARENA_ALIGN to align the Metablocks and > Metachunk header. This forced all allocations of metadata to be 16 > bytes aligned. This patch patch changes the restriction to be 8 bytes > instead, since that's the restriction needed for 64 bit types like > long, double, pointers and klass pointers, > > > Testing: Added unit test for Metachunk. JPRT (before splitting of the > patches) > > thanks, > StefanK From coleen.phillimore at oracle.com Mon Oct 14 14:31:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 14 Oct 2013 17:31:15 -0400 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525C56A0.3000408@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> Message-ID: <525C62A3.5090900@oracle.com> I think this looks good but I didn't review it completely. I had the opposite request as Jon though. I think "Metamem" is odd and if there's no reason to abbreviate something used only a couple places. Can you name the class Metamemory? And leave the file name metachunk? We have a lot of examples where the base class is not the same as the name of the file and the file is named after the class that the JVM uses outside the file (eg. growableArray.hpp). Now I've reviewed it. I think the Metamemory refactoring. Thanks, Coleen On 10/14/2013 04:40 PM, Jon Masamitsu wrote: > Comments only on the first patch. > > Looks good. Couple of questions. > > Why the change from _is_free to _is_marked_free? > > From > > 58 bool _is_free; > > to > > 105 DEBUG_ONLY(bool _is_marked_free;) > > > Is it to specifically distinguish it from the FreeChunk is_free()? > > The "marked" in the name feels a little like GC when it > isn't GC related. Would "_is_tagged_free" make sense? > > > Did you consider changing the file names from Metachunk.* to > Metamem.*? The file contains the classes Metamem, Metablock, > and Metachunk. It sees more natural to me to have the file named > after the more general Metamem class. Then all the classes in > the file are Metamem (or derived from), yes? > > Jon > > On 10/14/13 4:58 AM, Stefan Karlsson wrote: >> Please, review these two patches to remove some of the wastages >> introduced in the metaspace. >> >> >> 8026391: The Metachunk header wastes memory >> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8026391 >> >> There are a couple of fields in Metachunk that store already known >> information, like the beginning and the end of the Metachunk. I >> replaced those fields with code instead. >> >> To make this easier, I extracted some duplicated code in Metablock >> and Metachunk into a super class named Metamem. The extracted code is >> purely needed to allow these objects to be placed on the FreeList and >> in the BinaryTreeDictionary. >> >> >> 8026392: Metachunks and Metablocks are using a too large alignment >> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8026392 >> >> The metaspace code was using ARENA_ALIGN to align the Metablocks and >> Metachunk header. This forced all allocations of metadata to be 16 >> bytes aligned. This patch patch changes the restriction to be 8 bytes >> instead, since that's the restriction needed for 64 bit types like >> long, double, pointers and klass pointers, >> >> >> Testing: Added unit test for Metachunk. JPRT (before splitting of the >> patches) >> >> thanks, >> StefanK > From jon.masamitsu at oracle.com Mon Oct 14 15:46:45 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 14 Oct 2013 15:46:45 -0700 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525C62A3.5090900@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> <525C62A3.5090900@oracle.com> Message-ID: <525C7455.6010908@oracle.com> On 10/14/13 2:31 PM, Coleen Phillimore wrote: > > I think this looks good but I didn't review it completely. I had the > opposite request as Jon though. I think "Metamem" is odd and if > there's no reason to abbreviate something used only a couple places. > Can you name the class Metamemory? And leave the file name > metachunk? We have a lot of examples where the base class is not the > same as the name of the file and the file is named after the class > that the JVM uses outside the file (eg. growableArray.hpp). I would go along with that except that Metablock is in the same file so you have 2 VM visible types in the same file that is named after one of them. I'll grant you the longer name Metamemory. I think it's a little ugly. Metabase? Jon > > Now I've reviewed it. I think the Metamemory refactoring. > > Thanks, > Coleen > > > On 10/14/2013 04:40 PM, Jon Masamitsu wrote: >> Comments only on the first patch. >> >> Looks good. Couple of questions. >> >> Why the change from _is_free to _is_marked_free? >> >> From >> >> 58 bool _is_free; >> >> to >> >> 105 DEBUG_ONLY(bool _is_marked_free;) >> >> >> Is it to specifically distinguish it from the FreeChunk is_free()? >> >> The "marked" in the name feels a little like GC when it >> isn't GC related. Would "_is_tagged_free" make sense? >> >> >> Did you consider changing the file names from Metachunk.* to >> Metamem.*? The file contains the classes Metamem, Metablock, >> and Metachunk. It sees more natural to me to have the file named >> after the more general Metamem class. Then all the classes in >> the file are Metamem (or derived from), yes? >> >> Jon >> >> On 10/14/13 4:58 AM, Stefan Karlsson wrote: >>> Please, review these two patches to remove some of the wastages >>> introduced in the metaspace. >>> >>> >>> 8026391: The Metachunk header wastes memory >>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>> >>> There are a couple of fields in Metachunk that store already known >>> information, like the beginning and the end of the Metachunk. I >>> replaced those fields with code instead. >>> >>> To make this easier, I extracted some duplicated code in Metablock >>> and Metachunk into a super class named Metamem. The extracted code >>> is purely needed to allow these objects to be placed on the FreeList >>> and in the BinaryTreeDictionary. >>> >>> >>> 8026392: Metachunks and Metablocks are using a too large alignment >>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>> >>> The metaspace code was using ARENA_ALIGN to align the Metablocks and >>> Metachunk header. This forced all allocations of metadata to be 16 >>> bytes aligned. This patch patch changes the restriction to be 8 >>> bytes instead, since that's the restriction needed for 64 bit types >>> like long, double, pointers and klass pointers, >>> >>> >>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>> the patches) >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Mon Oct 14 22:56:25 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Oct 2013 07:56:25 +0200 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525C56A0.3000408@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> Message-ID: <525CD909.4010806@oracle.com> On 2013-10-14 22:40, Jon Masamitsu wrote: > Comments only on the first patch. > > Looks good. Couple of questions. > > Why the change from _is_free to _is_marked_free? > > From > > 58 bool _is_free; > > to > > 105 DEBUG_ONLY(bool _is_marked_free;) > > > Is it to specifically distinguish it from the FreeChunk is_free()? Yes. > > The "marked" in the name feels a little like GC when it > isn't GC related. Would "_is_tagged_free" make sense? Sounds good. I'll change it. > > > Did you consider changing the file names from Metachunk.* to > Metamem.*? The file contains the classes Metamem, Metablock, > and Metachunk. It sees more natural to me to have the file named > after the more general Metamem class. Then all the classes in > the file are Metamem (or derived from), yes? Coleen, has the opposite opinion. See answers to the other mails. thanks, StefanK > > Jon > > On 10/14/13 4:58 AM, Stefan Karlsson wrote: >> Please, review these two patches to remove some of the wastages >> introduced in the metaspace. >> >> >> 8026391: The Metachunk header wastes memory >> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8026391 >> >> There are a couple of fields in Metachunk that store already known >> information, like the beginning and the end of the Metachunk. I >> replaced those fields with code instead. >> >> To make this easier, I extracted some duplicated code in Metablock >> and Metachunk into a super class named Metamem. The extracted code is >> purely needed to allow these objects to be placed on the FreeList and >> in the BinaryTreeDictionary. >> >> >> 8026392: Metachunks and Metablocks are using a too large alignment >> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8026392 >> >> The metaspace code was using ARENA_ALIGN to align the Metablocks and >> Metachunk header. This forced all allocations of metadata to be 16 >> bytes aligned. This patch patch changes the restriction to be 8 bytes >> instead, since that's the restriction needed for 64 bit types like >> long, double, pointers and klass pointers, >> >> >> Testing: Added unit test for Metachunk. JPRT (before splitting of the >> patches) >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Mon Oct 14 22:58:06 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Oct 2013 07:58:06 +0200 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525C62A3.5090900@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> <525C62A3.5090900@oracle.com> Message-ID: <525CD96E.7090503@oracle.com> On 2013-10-14 23:31, Coleen Phillimore wrote: > > I think this looks good but I didn't review it completely. I had the > opposite request as Jon though. I think "Metamem" is odd and if > there's no reason to abbreviate something used only a couple places. > Can you name the class Metamemory? And leave the file name > metachunk? We have a lot of examples where the base class is not the > same as the name of the file and the file is named after the class > that the JVM uses outside the file (eg. growableArray.hpp). > > Now I've reviewed it. I think the Metamemory refactoring. I'll leave the code in the metachunk files, as you have requested. I'm open for a rename of Metamem, but Jon had another request for the name. See his next mail. thanks, StefanK > > Thanks, > Coleen > > > On 10/14/2013 04:40 PM, Jon Masamitsu wrote: >> Comments only on the first patch. >> >> Looks good. Couple of questions. >> >> Why the change from _is_free to _is_marked_free? >> >> From >> >> 58 bool _is_free; >> >> to >> >> 105 DEBUG_ONLY(bool _is_marked_free;) >> >> >> Is it to specifically distinguish it from the FreeChunk is_free()? >> >> The "marked" in the name feels a little like GC when it >> isn't GC related. Would "_is_tagged_free" make sense? >> >> >> Did you consider changing the file names from Metachunk.* to >> Metamem.*? The file contains the classes Metamem, Metablock, >> and Metachunk. It sees more natural to me to have the file named >> after the more general Metamem class. Then all the classes in >> the file are Metamem (or derived from), yes? >> >> Jon >> >> On 10/14/13 4:58 AM, Stefan Karlsson wrote: >>> Please, review these two patches to remove some of the wastages >>> introduced in the metaspace. >>> >>> >>> 8026391: The Metachunk header wastes memory >>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>> >>> There are a couple of fields in Metachunk that store already known >>> information, like the beginning and the end of the Metachunk. I >>> replaced those fields with code instead. >>> >>> To make this easier, I extracted some duplicated code in Metablock >>> and Metachunk into a super class named Metamem. The extracted code >>> is purely needed to allow these objects to be placed on the FreeList >>> and in the BinaryTreeDictionary. >>> >>> >>> 8026392: Metachunks and Metablocks are using a too large alignment >>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>> >>> The metaspace code was using ARENA_ALIGN to align the Metablocks and >>> Metachunk header. This forced all allocations of metadata to be 16 >>> bytes aligned. This patch patch changes the restriction to be 8 >>> bytes instead, since that's the restriction needed for 64 bit types >>> like long, double, pointers and klass pointers, >>> >>> >>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>> the patches) >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Mon Oct 14 23:02:58 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Oct 2013 08:02:58 +0200 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525C7455.6010908@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> <525C62A3.5090900@oracle.com> <525C7455.6010908@oracle.com> Message-ID: <525CDA92.6090607@oracle.com> On 2013-10-15 00:46, Jon Masamitsu wrote: > > On 10/14/13 2:31 PM, Coleen Phillimore wrote: >> >> I think this looks good but I didn't review it completely. I had the >> opposite request as Jon though. I think "Metamem" is odd and if >> there's no reason to abbreviate something used only a couple places. >> Can you name the class Metamemory? And leave the file name >> metachunk? We have a lot of examples where the base class is not the >> same as the name of the file and the file is named after the class >> that the JVM uses outside the file (eg. growableArray.hpp). > > I would go along with that except that Metablock is in the same file so > you have 2 VM visible types in the same file that is named after one > of them. I'll grant you the longer name Metamemory. I think it's a > little ugly. Metabase? I'll change Metamem to Metabase and leave the three classes in the metachunk files, for now. I'll do the renaming as a separate patch when we've figured out a good name and file separation. thanks! StefanK > > Jon > >> >> Now I've reviewed it. I think the Metamemory refactoring. >> >> Thanks, >> Coleen >> >> >> On 10/14/2013 04:40 PM, Jon Masamitsu wrote: >>> Comments only on the first patch. >>> >>> Looks good. Couple of questions. >>> >>> Why the change from _is_free to _is_marked_free? >>> >>> From >>> >>> 58 bool _is_free; >>> >>> to >>> >>> 105 DEBUG_ONLY(bool _is_marked_free;) >>> >>> >>> Is it to specifically distinguish it from the FreeChunk is_free()? >>> >>> The "marked" in the name feels a little like GC when it >>> isn't GC related. Would "_is_tagged_free" make sense? >>> >>> >>> Did you consider changing the file names from Metachunk.* to >>> Metamem.*? The file contains the classes Metamem, Metablock, >>> and Metachunk. It sees more natural to me to have the file named >>> after the more general Metamem class. Then all the classes in >>> the file are Metamem (or derived from), yes? >>> >>> Jon >>> >>> On 10/14/13 4:58 AM, Stefan Karlsson wrote: >>>> Please, review these two patches to remove some of the wastages >>>> introduced in the metaspace. >>>> >>>> >>>> 8026391: The Metachunk header wastes memory >>>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>>> >>>> There are a couple of fields in Metachunk that store already known >>>> information, like the beginning and the end of the Metachunk. I >>>> replaced those fields with code instead. >>>> >>>> To make this easier, I extracted some duplicated code in Metablock >>>> and Metachunk into a super class named Metamem. The extracted code >>>> is purely needed to allow these objects to be placed on the >>>> FreeList and in the BinaryTreeDictionary. >>>> >>>> >>>> 8026392: Metachunks and Metablocks are using a too large alignment >>>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>>> >>>> The metaspace code was using ARENA_ALIGN to align the Metablocks >>>> and Metachunk header. This forced all allocations of metadata to be >>>> 16 bytes aligned. This patch patch changes the restriction to be 8 >>>> bytes instead, since that's the restriction needed for 64 bit types >>>> like long, double, pointers and klass pointers, >>>> >>>> >>>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>>> the patches) >>>> >>>> thanks, >>>> StefanK >>> >> > From goetz.lindenmaier at sap.com Tue Oct 15 00:15:35 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Oct 2013 07:15:35 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0D04097D@DEWDFEMB12A.global.corp.sap> Hi, could I please get a review on this change? I would appreciate any comments. Thanks and best regards, Goetz. From: goetz.lindenmaier at sap.com Sent: Mittwoch, 2. Oktober 2013 15:49 To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. Hi, we extended C2 by what we call lateExpand. LateExpand expands nodes after register allocation. http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ Some nodes can not be expanded during matching. E.g., register allocation might not be able to deal with the resulting pattern. To allow better scheduling in such cases, we introduce lateExpand which runs after register allocation. Whether and how nodes are expanded is specified in the ad-file. See block.cpp for a detailed documentation. We use this for some nodes on ppc, and extensively on ia64. For an example, see the webrev. We added some utility functions in node.hpp and block.hpp used by PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, MachConstantBaseNode gets the two new functions, as we need to late expand it. To skip the walk over the IR if no lateExpand is needed, we use Matcher::require_late_expand set in the ad file. This ends up in ad_.cpp, thus can not be evaluated by the C++ compiler. If you agree, I would use a "const bool EnableLateExpand" in globalDefinitions_.hpp. (There is no suitable c2__.hpp file). We allready mailed a webrev with this change after last year's JavaOne, but there was no discussion on it. Again, this change is 'L', but the code is not used on other platforms than PPC64 (so far). So the impact on those platforms should be minimal. Please review and test this change. Thanks and best regards, Goetz. From david.holmes at oracle.com Tue Oct 15 00:48:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 17:48:52 +1000 Subject: RFR: JDK-8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. In-Reply-To: <525BB895.3020906@oracle.com> References: <525BB895.3020906@oracle.com> Message-ID: <525CF364.8040608@oracle.com> On 14/10/2013 7:25 PM, Erik Joelsson wrote: > Please review the following changes, correcting the conditions for when > to build certain parts of the servicability features. Instead of > guarding them with the OPENJDK variable, they need to be conditioned on > the existence of the source itself. > > In hotspot, this only fails on Windows. The linux makefiles already > check on the existence of the source rather than if it's an OPENJDK > build. This change makes windows do the same. > > http://cr.openjdk.java.net/~erikj/8019540/webrev.hotspot.01/ This is an expedient fix. More generally though these kinds of things should really be in the closed makefiles. That of course requires a suitable closed makefile which doesn't presently exist. > In JDK, it fails on all platforms. There is already a configure > variable, ENABLE_JFR, that seems to be set correctly for this case. > > http://cr.openjdk.java.net/~erikj/8019540/webrev.jdk.01/ Ok. > I will need a sponsor to push this to hotspot if it passes review. You will need a separate bug for the JDK and hotspot side due to the different version info used by each. Otherwise the hgupdater will get in a tangle with the backports. David ----- > /Erik From coleen.phillimore at oracle.com Tue Oct 15 05:06:49 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Oct 2013 08:06:49 -0400 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525CDA92.6090607@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> <525C62A3.5090900@oracle.com> <525C7455.6010908@oracle.com> <525CDA92.6090607@oracle.com> Message-ID: <525D2FD9.9060604@oracle.com> On 10/15/2013 2:02 AM, Stefan Karlsson wrote: > On 2013-10-15 00:46, Jon Masamitsu wrote: >> >> On 10/14/13 2:31 PM, Coleen Phillimore wrote: >>> >>> I think this looks good but I didn't review it completely. I had >>> the opposite request as Jon though. I think "Metamem" is odd and if >>> there's no reason to abbreviate something used only a couple >>> places. Can you name the class Metamemory? And leave the file name >>> metachunk? We have a lot of examples where the base class is not >>> the same as the name of the file and the file is named after the >>> class that the JVM uses outside the file (eg. growableArray.hpp). >> >> I would go along with that except that Metablock is in the same file so >> you have 2 VM visible types in the same file that is named after one >> of them. I'll grant you the longer name Metamemory. I think it's a >> little ugly. Metabase? > > I'll change Metamem to Metabase and leave the three classes in the > metachunk files, for now. Sure. > > I'll do the renaming as a separate patch when we've figured out a good > name and file separation. I don't think this looks so bad as Metablock and Metachunk are mostly internal to metaspace anyway. Rename MetaspaceAux first! Thanks, Coleen > > thanks! > StefanK >> >> Jon >> >>> >>> Now I've reviewed it. I think the Metamemory refactoring. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 10/14/2013 04:40 PM, Jon Masamitsu wrote: >>>> Comments only on the first patch. >>>> >>>> Looks good. Couple of questions. >>>> >>>> Why the change from _is_free to _is_marked_free? >>>> >>>> From >>>> >>>> 58 bool _is_free; >>>> >>>> to >>>> >>>> 105 DEBUG_ONLY(bool _is_marked_free;) >>>> >>>> >>>> Is it to specifically distinguish it from the FreeChunk is_free()? >>>> >>>> The "marked" in the name feels a little like GC when it >>>> isn't GC related. Would "_is_tagged_free" make sense? >>>> >>>> >>>> Did you consider changing the file names from Metachunk.* to >>>> Metamem.*? The file contains the classes Metamem, Metablock, >>>> and Metachunk. It sees more natural to me to have the file named >>>> after the more general Metamem class. Then all the classes in >>>> the file are Metamem (or derived from), yes? >>>> >>>> Jon >>>> >>>> On 10/14/13 4:58 AM, Stefan Karlsson wrote: >>>>> Please, review these two patches to remove some of the wastages >>>>> introduced in the metaspace. >>>>> >>>>> >>>>> 8026391: The Metachunk header wastes memory >>>>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>>>> >>>>> There are a couple of fields in Metachunk that store already known >>>>> information, like the beginning and the end of the Metachunk. I >>>>> replaced those fields with code instead. >>>>> >>>>> To make this easier, I extracted some duplicated code in Metablock >>>>> and Metachunk into a super class named Metamem. The extracted code >>>>> is purely needed to allow these objects to be placed on the >>>>> FreeList and in the BinaryTreeDictionary. >>>>> >>>>> >>>>> 8026392: Metachunks and Metablocks are using a too large alignment >>>>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>>>> >>>>> The metaspace code was using ARENA_ALIGN to align the Metablocks >>>>> and Metachunk header. This forced all allocations of metadata to >>>>> be 16 bytes aligned. This patch patch changes the restriction to >>>>> be 8 bytes instead, since that's the restriction needed for 64 bit >>>>> types like long, double, pointers and klass pointers, >>>>> >>>>> >>>>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>>>> the patches) >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From stefan.karlsson at oracle.com Tue Oct 15 08:10:56 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Tue, 15 Oct 2013 15:10:56 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20131015151107.2D933623EC@hg.openjdk.java.net> Changeset: a453e8756d6f Author: stefank Date: 2013-10-15 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a453e8756d6f 8022507: SIGSEGV at ParMarkBitMap::verify_clear() Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages. Reviewed-by: tschatzl, dcubed, brutisso ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! 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/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4911caf5a68d Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4911caf5a68d 8026486: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java ! test/testlibrary/OutputAnalyzerTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java From jon.masamitsu at oracle.com Tue Oct 15 08:23:15 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Oct 2013 08:23:15 -0700 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525CDA92.6090607@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> <525C62A3.5090900@oracle.com> <525C7455.6010908@oracle.com> <525CDA92.6090607@oracle.com> Message-ID: <525D5DE3.5030205@oracle.com> On 10/14/13 11:02 PM, Stefan Karlsson wrote: > On 2013-10-15 00:46, Jon Masamitsu wrote: >> >> On 10/14/13 2:31 PM, Coleen Phillimore wrote: >>> >>> I think this looks good but I didn't review it completely. I had >>> the opposite request as Jon though. I think "Metamem" is odd and if >>> there's no reason to abbreviate something used only a couple >>> places. Can you name the class Metamemory? And leave the file name >>> metachunk? We have a lot of examples where the base class is not >>> the same as the name of the file and the file is named after the >>> class that the JVM uses outside the file (eg. growableArray.hpp). >> >> I would go along with that except that Metablock is in the same file so >> you have 2 VM visible types in the same file that is named after one >> of them. I'll grant you the longer name Metamemory. I think it's a >> little ugly. Metabase? > > I'll change Metamem to Metabase and leave the three classes in the > metachunk files, for now. Thanks (for name change) and OK (on metachunk files). Jon > > I'll do the renaming as a separate patch when we've figured out a good > name and file separation. > > thanks! > StefanK >> >> Jon >> >>> >>> Now I've reviewed it. I think the Metamemory refactoring. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 10/14/2013 04:40 PM, Jon Masamitsu wrote: >>>> Comments only on the first patch. >>>> >>>> Looks good. Couple of questions. >>>> >>>> Why the change from _is_free to _is_marked_free? >>>> >>>> From >>>> >>>> 58 bool _is_free; >>>> >>>> to >>>> >>>> 105 DEBUG_ONLY(bool _is_marked_free;) >>>> >>>> >>>> Is it to specifically distinguish it from the FreeChunk is_free()? >>>> >>>> The "marked" in the name feels a little like GC when it >>>> isn't GC related. Would "_is_tagged_free" make sense? >>>> >>>> >>>> Did you consider changing the file names from Metachunk.* to >>>> Metamem.*? The file contains the classes Metamem, Metablock, >>>> and Metachunk. It sees more natural to me to have the file named >>>> after the more general Metamem class. Then all the classes in >>>> the file are Metamem (or derived from), yes? >>>> >>>> Jon >>>> >>>> On 10/14/13 4:58 AM, Stefan Karlsson wrote: >>>>> Please, review these two patches to remove some of the wastages >>>>> introduced in the metaspace. >>>>> >>>>> >>>>> 8026391: The Metachunk header wastes memory >>>>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>>>> >>>>> There are a couple of fields in Metachunk that store already known >>>>> information, like the beginning and the end of the Metachunk. I >>>>> replaced those fields with code instead. >>>>> >>>>> To make this easier, I extracted some duplicated code in Metablock >>>>> and Metachunk into a super class named Metamem. The extracted code >>>>> is purely needed to allow these objects to be placed on the >>>>> FreeList and in the BinaryTreeDictionary. >>>>> >>>>> >>>>> 8026392: Metachunks and Metablocks are using a too large alignment >>>>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>>>> >>>>> The metaspace code was using ARENA_ALIGN to align the Metablocks >>>>> and Metachunk header. This forced all allocations of metadata to >>>>> be 16 bytes aligned. This patch patch changes the restriction to >>>>> be 8 bytes instead, since that's the restriction needed for 64 bit >>>>> types like long, double, pointers and klass pointers, >>>>> >>>>> >>>>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>>>> the patches) >>>>> >>>>> thanks, >>>>> StefanK >>>> >>> >> > From jon.masamitsu at oracle.com Tue Oct 15 08:30:30 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Oct 2013 08:30:30 -0700 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525D2FD9.9060604@oracle.com> References: <525BDC67.1040902@oracle.com> <525C56A0.3000408@oracle.com> <525C62A3.5090900@oracle.com> <525C7455.6010908@oracle.com> <525CDA92.6090607@oracle.com> <525D2FD9.9060604@oracle.com> Message-ID: <525D5F96.9020104@oracle.com> On 10/15/13 5:06 AM, Coleen Phillimore wrote: > On 10/15/2013 2:02 AM, Stefan Karlsson wrote: >> On 2013-10-15 00:46, Jon Masamitsu wrote: >>> >>> On 10/14/13 2:31 PM, Coleen Phillimore wrote: >>>> >>>> I think this looks good but I didn't review it completely. I had >>>> the opposite request as Jon though. I think "Metamem" is odd and >>>> if there's no reason to abbreviate something used only a couple >>>> places. Can you name the class Metamemory? And leave the file name >>>> metachunk? We have a lot of examples where the base class is not >>>> the same as the name of the file and the file is named after the >>>> class that the JVM uses outside the file (eg. growableArray.hpp). >>> >>> I would go along with that except that Metablock is in the same file so >>> you have 2 VM visible types in the same file that is named after one >>> of them. I'll grant you the longer name Metamemory. I think it's a >>> little ugly. Metabase? >> >> I'll change Metamem to Metabase and leave the three classes in the >> metachunk files, for now. > > Sure. >> >> I'll do the renaming as a separate patch when we've figured out a >> good name and file separation. > > I don't think this looks so bad as Metablock and Metachunk are mostly > internal to metaspace anyway. I don't insist on a file separation change. > Rename MetaspaceAux first! Give us a new name! :-) Jon > > Thanks, > Coleen > >> >> thanks! >> StefanK >>> >>> Jon >>> >>>> >>>> Now I've reviewed it. I think the Metamemory refactoring. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 10/14/2013 04:40 PM, Jon Masamitsu wrote: >>>>> Comments only on the first patch. >>>>> >>>>> Looks good. Couple of questions. >>>>> >>>>> Why the change from _is_free to _is_marked_free? >>>>> >>>>> From >>>>> >>>>> 58 bool _is_free; >>>>> >>>>> to >>>>> >>>>> 105 DEBUG_ONLY(bool _is_marked_free;) >>>>> >>>>> >>>>> Is it to specifically distinguish it from the FreeChunk is_free()? >>>>> >>>>> The "marked" in the name feels a little like GC when it >>>>> isn't GC related. Would "_is_tagged_free" make sense? >>>>> >>>>> >>>>> Did you consider changing the file names from Metachunk.* to >>>>> Metamem.*? The file contains the classes Metamem, Metablock, >>>>> and Metachunk. It sees more natural to me to have the file named >>>>> after the more general Metamem class. Then all the classes in >>>>> the file are Metamem (or derived from), yes? >>>>> >>>>> Jon >>>>> >>>>> On 10/14/13 4:58 AM, Stefan Karlsson wrote: >>>>>> Please, review these two patches to remove some of the wastages >>>>>> introduced in the metaspace. >>>>>> >>>>>> >>>>>> 8026391: The Metachunk header wastes memory >>>>>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>>>>> >>>>>> There are a couple of fields in Metachunk that store already >>>>>> known information, like the beginning and the end of the >>>>>> Metachunk. I replaced those fields with code instead. >>>>>> >>>>>> To make this easier, I extracted some duplicated code in >>>>>> Metablock and Metachunk into a super class named Metamem. The >>>>>> extracted code is purely needed to allow these objects to be >>>>>> placed on the FreeList and in the BinaryTreeDictionary. >>>>>> >>>>>> >>>>>> 8026392: Metachunks and Metablocks are using a too large alignment >>>>>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>>>>> >>>>>> The metaspace code was using ARENA_ALIGN to align the Metablocks >>>>>> and Metachunk header. This forced all allocations of metadata to >>>>>> be 16 bytes aligned. This patch patch changes the restriction to >>>>>> be 8 bytes instead, since that's the restriction needed for 64 >>>>>> bit types like long, double, pointers and klass pointers, >>>>>> >>>>>> >>>>>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>>>>> the patches) >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>> >>>> >>> >> > From volker.simonis at gmail.com Tue Oct 15 08:41:54 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Oct 2013 17:41:54 +0200 Subject: RFR(S): 8026487 : PPC64: Implement 'os::fork_and_exec' on AIX Message-ID: Hi, could you please review the following webrev: http://cr.openjdk.java.net/~simonis/webrevs/8026487/ for bug: https://bugs.openjdk.java.net/browse/JDK-8026487 which only touches the AIX specific file src/os/aix/vm/os_aix.cpp. Here's some background: During testing with the OpenJDK regression tests we realized that we've omitted the implementation of os::fork_and_exec() on AIX. This method is only required by the options -XX:OnOutOfMemoryError, -XX:OnError and -XX:+ShowMessageBoxOnError if the user answers with 'yes'. The implementation is a straightforward adaptation of the corresponding Linux code. This change also contains the trivial implementation of os::Aix::available_memory() which is only used by the trace macro RC_TRACE_WITH_THREAD in VM_RedefineClasses. The implementation simply calls os::Aix::get_meminfo() which had been already implemented before. Regards, Volker From stefan.karlsson at oracle.com Tue Oct 15 11:11:24 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Oct 2013 20:11:24 +0200 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525BDC67.1040902@oracle.com> References: <525BDC67.1040902@oracle.com> Message-ID: <525D854C.6020909@oracle.com> From an offline discussion with Jon, I decided to change the following: $ hg diff diff -r 8e2b57a0132c src/share/vm/memory/metachunk.cpp --- a/src/share/vm/memory/metachunk.cpp Tue Oct 15 14:32:20 2013 +0200 +++ b/src/share/vm/memory/metachunk.cpp Tue Oct 15 20:07:51 2013 +0200 @@ -37,8 +37,8 @@ // so that 64 bit types get correctly aligned. const size_t alignment = 8; + // Make sure that the Klass alignment also agree. STATIC_ASSERT(alignment == (size_t)KlassAlignmentInBytes); - STATIC_ASSERT(alignment == (size_t)BytesPerLong); return alignment; } StefanK On 10/14/13 1:58 PM, Stefan Karlsson wrote: > Please, review these two patches to remove some of the wastages > introduced in the metaspace. > > > 8026391: The Metachunk header wastes memory > http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8026391 > > There are a couple of fields in Metachunk that store already known > information, like the beginning and the end of the Metachunk. I > replaced those fields with code instead. > > To make this easier, I extracted some duplicated code in Metablock and > Metachunk into a super class named Metamem. The extracted code is > purely needed to allow these objects to be placed on the FreeList and > in the BinaryTreeDictionary. > > > 8026392: Metachunks and Metablocks are using a too large alignment > http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8026392 > > The metaspace code was using ARENA_ALIGN to align the Metablocks and > Metachunk header. This forced all allocations of metadata to be 16 > bytes aligned. This patch patch changes the restriction to be 8 bytes > instead, since that's the restriction needed for 64 bit types like > long, double, pointers and klass pointers, > > > Testing: Added unit test for Metachunk. JPRT (before splitting of the > patches) > > thanks, > StefanK From christian.thalinger at oracle.com Tue Oct 15 11:53:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Oct 2013 11:53:52 -0700 Subject: RFR(S): 8026487 : PPC64: Implement 'os::fork_and_exec' on AIX In-Reply-To: References: Message-ID: I know nothing about AIX but I assume you've tested the change and it works, right? Looks good. On Oct 15, 2013, at 8:41 AM, Volker Simonis wrote: > Hi, > > could you please review the following webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8026487/ > > for bug: > > https://bugs.openjdk.java.net/browse/JDK-8026487 > > which only touches the AIX specific file src/os/aix/vm/os_aix.cpp. > > Here's some background: > > During testing with the OpenJDK regression tests we realized that > we've omitted the implementation of os::fork_and_exec() on AIX. This > method is only required by the options -XX:OnOutOfMemoryError, > -XX:OnError and -XX:+ShowMessageBoxOnError if the user answers with > 'yes'. > > The implementation is a straightforward adaptation of the > corresponding Linux code. > > This change also contains the trivial implementation of > os::Aix::available_memory() which is only used by the trace macro > RC_TRACE_WITH_THREAD in VM_RedefineClasses. The implementation simply > calls os::Aix::get_meminfo() which had been already implemented > before. > > Regards, > Volker From vladimir.kozlov at oracle.com Tue Oct 15 12:23:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 12:23:52 -0700 Subject: RFR(S): 8026487 : PPC64: Implement 'os::fork_and_exec' on AIX In-Reply-To: References: Message-ID: <525D9648.5090303@oracle.com> Looks good to me too. You can push it. Thanks, Vladimir On 10/15/13 8:41 AM, Volker Simonis wrote: > Hi, > > could you please review the following webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8026487/ > > for bug: > > https://bugs.openjdk.java.net/browse/JDK-8026487 > > which only touches the AIX specific file src/os/aix/vm/os_aix.cpp. > > Here's some background: > > During testing with the OpenJDK regression tests we realized that > we've omitted the implementation of os::fork_and_exec() on AIX. This > method is only required by the options -XX:OnOutOfMemoryError, > -XX:OnError and -XX:+ShowMessageBoxOnError if the user answers with > 'yes'. > > The implementation is a straightforward adaptation of the > corresponding Linux code. > > This change also contains the trivial implementation of > os::Aix::available_memory() which is only used by the trace macro > RC_TRACE_WITH_THREAD in VM_RedefineClasses. The implementation simply > calls os::Aix::get_meminfo() which had been already implemented > before. > > Regards, > Volker > From vladimir.kozlov at oracle.com Tue Oct 15 12:28:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 12:28:21 -0700 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D04097D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0D04097D@DEWDFEMB12A.global.corp.sap> Message-ID: <525D9755.9000000@oracle.com> Goetz, Sorry but currently we don't have time to review this and part 113 changes. They affect shared code and are relatively big so we need to review them carefully. And now we are very very busy with fixing/cleaning bugs for jkd8 release. Please, wait 2 more weeks. Regards, Vladimir On 10/15/13 12:15 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review on this change? I would appreciate any comments. > > Thanks and best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Mittwoch, 2. Oktober 2013 15:49 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' > Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Hi, > > we extended C2 by what we call lateExpand. LateExpand expands nodes > after register allocation. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Some nodes can not be expanded during matching. E.g., register > allocation might not be able to deal with the resulting pattern. To > allow better scheduling in such cases, we introduce lateExpand which > runs after register allocation. Whether and how nodes are expanded is > specified in the ad-file. See block.cpp for a detailed > documentation. We use this for some nodes on ppc, and extensively on > ia64. > For an example, see the webrev. > > We added some utility functions in node.hpp and block.hpp used by > PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, > MachConstantBaseNode gets the two new functions, as we need to > late expand it. > > To skip the walk over the IR if no lateExpand is needed, we use > Matcher::require_late_expand set in the ad file. This ends up in > ad_.cpp, thus can not be evaluated by the C++ compiler. If you > agree, I would use a "const bool EnableLateExpand" in > globalDefinitions_.hpp. (There is no suitable c2__.hpp > file). > > We allready mailed a webrev with this change after last year's > JavaOne, but there was no discussion on it. > Again, this change is 'L', but the code is not used on other > platforms than PPC64 (so far). So the impact on those platforms > should be minimal. > > Please review and test this change. > > Thanks and best regards, > Goetz. > From coleen.phillimore at oracle.com Tue Oct 15 13:01:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Oct 2013 16:01:34 -0400 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525D854C.6020909@oracle.com> References: <525BDC67.1040902@oracle.com> <525D854C.6020909@oracle.com> Message-ID: <525D9F1E.3060700@oracle.com> This is good, so we align metachunks to 8 byte alignment rather than 16 in 64 bit? #define ARENA_AMALLOC_ALIGNMENT (2*BytesPerWord) Coleen On 10/15/2013 02:11 PM, Stefan Karlsson wrote: > From an offline discussion with Jon, I decided to change the following: > > $ hg diff > diff -r 8e2b57a0132c src/share/vm/memory/metachunk.cpp > --- a/src/share/vm/memory/metachunk.cpp Tue Oct 15 14:32:20 2013 +0200 > +++ b/src/share/vm/memory/metachunk.cpp Tue Oct 15 20:07:51 2013 +0200 > @@ -37,8 +37,8 @@ > // so that 64 bit types get correctly aligned. > const size_t alignment = 8; > > + // Make sure that the Klass alignment also agree. > STATIC_ASSERT(alignment == (size_t)KlassAlignmentInBytes); > - STATIC_ASSERT(alignment == (size_t)BytesPerLong); > > return alignment; > } > > StefanK > > On 10/14/13 1:58 PM, Stefan Karlsson wrote: >> Please, review these two patches to remove some of the wastages >> introduced in the metaspace. >> >> >> 8026391: The Metachunk header wastes memory >> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8026391 >> >> There are a couple of fields in Metachunk that store already known >> information, like the beginning and the end of the Metachunk. I >> replaced those fields with code instead. >> >> To make this easier, I extracted some duplicated code in Metablock >> and Metachunk into a super class named Metamem. The extracted code is >> purely needed to allow these objects to be placed on the FreeList and >> in the BinaryTreeDictionary. >> >> >> 8026392: Metachunks and Metablocks are using a too large alignment >> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8026392 >> >> The metaspace code was using ARENA_ALIGN to align the Metablocks and >> Metachunk header. This forced all allocations of metadata to be 16 >> bytes aligned. This patch patch changes the restriction to be 8 bytes >> instead, since that's the restriction needed for 64 bit types like >> long, double, pointers and klass pointers, >> >> >> Testing: Added unit test for Metachunk. JPRT (before splitting of the >> patches) >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Tue Oct 15 13:26:32 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Oct 2013 22:26:32 +0200 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525D9F1E.3060700@oracle.com> References: <525BDC67.1040902@oracle.com> <525D854C.6020909@oracle.com> <525D9F1E.3060700@oracle.com> Message-ID: <525DA4F8.1010301@oracle.com> On 10/15/13 10:01 PM, Coleen Phillimore wrote: > > This is good, so we align metachunks to 8 byte alignment rather than > 16 in 64 bit? > #define ARENA_AMALLOC_ALIGNMENT (2*BytesPerWord) Yes. Just like we did with the PermGen. thanks, StefanK > > Coleen > > On 10/15/2013 02:11 PM, Stefan Karlsson wrote: >> From an offline discussion with Jon, I decided to change the following: >> >> $ hg diff >> diff -r 8e2b57a0132c src/share/vm/memory/metachunk.cpp >> --- a/src/share/vm/memory/metachunk.cpp Tue Oct 15 14:32:20 2013 >> +0200 >> +++ b/src/share/vm/memory/metachunk.cpp Tue Oct 15 20:07:51 2013 >> +0200 >> @@ -37,8 +37,8 @@ >> // so that 64 bit types get correctly aligned. >> const size_t alignment = 8; >> >> + // Make sure that the Klass alignment also agree. >> STATIC_ASSERT(alignment == (size_t)KlassAlignmentInBytes); >> - STATIC_ASSERT(alignment == (size_t)BytesPerLong); >> >> return alignment; >> } >> >> StefanK >> >> On 10/14/13 1:58 PM, Stefan Karlsson wrote: >>> Please, review these two patches to remove some of the wastages >>> introduced in the metaspace. >>> >>> >>> 8026391: The Metachunk header wastes memory >>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>> >>> There are a couple of fields in Metachunk that store already known >>> information, like the beginning and the end of the Metachunk. I >>> replaced those fields with code instead. >>> >>> To make this easier, I extracted some duplicated code in Metablock >>> and Metachunk into a super class named Metamem. The extracted code >>> is purely needed to allow these objects to be placed on the FreeList >>> and in the BinaryTreeDictionary. >>> >>> >>> 8026392: Metachunks and Metablocks are using a too large alignment >>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>> >>> The metaspace code was using ARENA_ALIGN to align the Metablocks and >>> Metachunk header. This forced all allocations of metadata to be 16 >>> bytes aligned. This patch patch changes the restriction to be 8 >>> bytes instead, since that's the restriction needed for 64 bit types >>> like long, double, pointers and klass pointers, >>> >>> >>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>> the patches) >>> >>> thanks, >>> StefanK >> > From coleen.phillimore at oracle.com Tue Oct 15 13:25:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Oct 2013 16:25:11 -0400 Subject: Review request: 8026391: The Metachunk header wastes memory - 8026392: Metachunks and Metablocks are using a too large alignment In-Reply-To: <525DA4F8.1010301@oracle.com> References: <525BDC67.1040902@oracle.com> <525D854C.6020909@oracle.com> <525D9F1E.3060700@oracle.com> <525DA4F8.1010301@oracle.com> Message-ID: <525DA4A7.4000107@oracle.com> On 10/15/2013 04:26 PM, Stefan Karlsson wrote: > On 10/15/13 10:01 PM, Coleen Phillimore wrote: >> >> This is good, so we align metachunks to 8 byte alignment rather than >> 16 in 64 bit? >> #define ARENA_AMALLOC_ALIGNMENT (2*BytesPerWord) > > Yes. Just like we did with the PermGen. PermGen? Do you remember PermGen?? :) Coleen > > thanks, > StefanK >> >> Coleen >> >> On 10/15/2013 02:11 PM, Stefan Karlsson wrote: >>> From an offline discussion with Jon, I decided to change the following: >>> >>> $ hg diff >>> diff -r 8e2b57a0132c src/share/vm/memory/metachunk.cpp >>> --- a/src/share/vm/memory/metachunk.cpp Tue Oct 15 14:32:20 2013 >>> +0200 >>> +++ b/src/share/vm/memory/metachunk.cpp Tue Oct 15 20:07:51 2013 >>> +0200 >>> @@ -37,8 +37,8 @@ >>> // so that 64 bit types get correctly aligned. >>> const size_t alignment = 8; >>> >>> + // Make sure that the Klass alignment also agree. >>> STATIC_ASSERT(alignment == (size_t)KlassAlignmentInBytes); >>> - STATIC_ASSERT(alignment == (size_t)BytesPerLong); >>> >>> return alignment; >>> } >>> >>> StefanK >>> >>> On 10/14/13 1:58 PM, Stefan Karlsson wrote: >>>> Please, review these two patches to remove some of the wastages >>>> introduced in the metaspace. >>>> >>>> >>>> 8026391: The Metachunk header wastes memory >>>> http://cr.openjdk.java.net/~stefank/8026391/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8026391 >>>> >>>> There are a couple of fields in Metachunk that store already known >>>> information, like the beginning and the end of the Metachunk. I >>>> replaced those fields with code instead. >>>> >>>> To make this easier, I extracted some duplicated code in Metablock >>>> and Metachunk into a super class named Metamem. The extracted code >>>> is purely needed to allow these objects to be placed on the >>>> FreeList and in the BinaryTreeDictionary. >>>> >>>> >>>> 8026392: Metachunks and Metablocks are using a too large alignment >>>> http://cr.openjdk.java.net/~stefank/8026392/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8026392 >>>> >>>> The metaspace code was using ARENA_ALIGN to align the Metablocks >>>> and Metachunk header. This forced all allocations of metadata to be >>>> 16 bytes aligned. This patch patch changes the restriction to be 8 >>>> bytes instead, since that's the restriction needed for 64 bit types >>>> like long, double, pointers and klass pointers, >>>> >>>> >>>> Testing: Added unit test for Metachunk. JPRT (before splitting of >>>> the patches) >>>> >>>> thanks, >>>> StefanK >>> >> > From david.holmes at oracle.com Tue Oct 15 21:06:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 14:06:42 +1000 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525D4490.3070506@oracle.com> References: <525D4490.3070506@oracle.com> Message-ID: <525E10D2.2060604@oracle.com> Hi Katja, Not a review just a couple of meta comments. First I've added hotspto-dev as all these changes to the test library need a wider review audience. I'm a little concerned about its current rate of expansion. Second all the new files have the wrong copyright notice - they should have the OpenJDK copyright. Thanks, David On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > The purpose of this fix is to get rid of intermittent failures in > sun/tools/jstatd tests and make the tests more stable, legible and > maintainable. > > Thanks, > Katja > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 From volker.simonis at gmail.com Wed Oct 16 01:59:37 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Oct 2013 10:59:37 +0200 Subject: RFR(S): 8026487 : PPC64: Implement 'os::fork_and_exec' on AIX In-Reply-To: <525D9648.5090303@oracle.com> References: <525D9648.5090303@oracle.com> Message-ID: Hi Christian, Vladimir, thanks for the fast review. I've just pushed the change to our staging repository. Regards, Volker On Tue, Oct 15, 2013 at 9:23 PM, Vladimir Kozlov wrote: > Looks good to me too. You can push it. > > Thanks, > Vladimir > > > On 10/15/13 8:41 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8026487/ >> >> for bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8026487 >> >> which only touches the AIX specific file src/os/aix/vm/os_aix.cpp. >> >> Here's some background: >> >> During testing with the OpenJDK regression tests we realized that >> we've omitted the implementation of os::fork_and_exec() on AIX. This >> method is only required by the options -XX:OnOutOfMemoryError, >> -XX:OnError and -XX:+ShowMessageBoxOnError if the user answers with >> 'yes'. >> >> The implementation is a straightforward adaptation of the >> corresponding Linux code. >> >> This change also contains the trivial implementation of >> os::Aix::available_memory() which is only used by the trace macro >> RC_TRACE_WITH_THREAD in VM_RedefineClasses. The implementation simply >> calls os::Aix::get_meminfo() which had been already implemented >> before. >> >> Regards, >> Volker >> > From roland.westrelin at oracle.com Wed Oct 16 05:44:07 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 Oct 2013 12:44:07 -0000 Subject: Result: New HSX Committer: David Chase Message-ID: Voting for David Chase [1] is now closed. Yes: 25 //Volker is last Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Best wishes, John Rose [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011064.html [2] http://openjdk.java.net/bylaws#lazy-consensus From volker.simonis at gmail.com Wed Oct 16 06:18:33 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Oct 2013 15:18:33 +0200 Subject: RFR(XS): 8026703 : Wrongly placed element in Event-Based JVM Tracing .xsl files Message-ID: Hi, could somebody please review and push the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/8026703/ https://bugs.openjdk.java.net/browse/JDK-8026703 Some background information: The three XSL files src/share/vm/trace/traceEventClasses.xsl src/share/vm/trace/traceEventIds.xsl src/share/vm/trace/traceTypes.xsl contain elements after elements. This is not allowed, because according to the XSLT specification (http://www.w3.org/TR/xslt#element-import) "xsl:import element children must precede all other element children of an xsl:stylesheet element". I do not know why the current OpenJDK XSLT processor doesn't object this (and maybe this should be the topic of another Bug/RFE), but other XSLT processors (i.e. the one in IBM J9) do care and this leads to build failures if building with a non-Oracle boot JDK. The fix is easy - just reorder the elements before the elements. Regards, Volker From kmcguigan at twitter.com Wed Oct 16 06:40:37 2013 From: kmcguigan at twitter.com (Keith McGuigan) Date: Wed, 16 Oct 2013 09:40:37 -0400 Subject: RFR(XS): 8026703 : Wrongly placed element in Event-Based JVM Tracing .xsl files In-Reply-To: References: Message-ID: Looks good. -- - Keith On Wed, Oct 16, 2013 at 9:18 AM, Volker Simonis wrote: > Hi, > > could somebody please review and push the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/8026703/ > https://bugs.openjdk.java.net/browse/JDK-8026703 > > Some background information: > > The three XSL files > > src/share/vm/trace/traceEventClasses.xsl > src/share/vm/trace/traceEventIds.xsl > src/share/vm/trace/traceTypes.xsl > > contain elements after elements. This is not > allowed, because according to the XSLT specification > (http://www.w3.org/TR/xslt#element-import) "xsl:import element > children must precede all other element children of an xsl:stylesheet > element". > > I do not know why the current OpenJDK XSLT processor doesn't object > this (and maybe this should be the topic of another Bug/RFE), but > other XSLT processors (i.e. the one in IBM J9) do care and this leads > to build failures if building with a non-Oracle boot JDK. > > The fix is easy - just reorder the elements before the > elements. > > Regards, > Volker > From stefan.karlsson at oracle.com Wed Oct 16 07:18:33 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Oct 2013 16:18:33 +0200 Subject: Review request: 8026707: JDK-8026391 broke the optimized build target Message-ID: <525EA039.7050004@oracle.com> http://cr.openjdk.java.net/~stefank/8026707/webrev.00/ Metachunk::mangle() was incorrectly moved being guarded by NOT_PRODUCT() to being guarded by ASSERT. The patch reverts that change. thanks, StefanK From staffan.larsen at oracle.com Wed Oct 16 07:29:40 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Oct 2013 16:29:40 +0200 Subject: RFR(XS): 8026703 : Wrongly placed element in Event-Based JVM Tracing .xsl files In-Reply-To: References: Message-ID: Looks good! Thanks, /Staffan On 16 okt 2013, at 15:18, Volker Simonis wrote: > Hi, > > could somebody please review and push the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/8026703/ > https://bugs.openjdk.java.net/browse/JDK-8026703 > > Some background information: > > The three XSL files > > src/share/vm/trace/traceEventClasses.xsl > src/share/vm/trace/traceEventIds.xsl > src/share/vm/trace/traceTypes.xsl > > contain elements after elements. This is not > allowed, because according to the XSLT specification > (http://www.w3.org/TR/xslt#element-import) "xsl:import element > children must precede all other element children of an xsl:stylesheet > element". > > I do not know why the current OpenJDK XSLT processor doesn't object > this (and maybe this should be the topic of another Bug/RFE), but > other XSLT processors (i.e. the one in IBM J9) do care and this leads > to build failures if building with a non-Oracle boot JDK. > > The fix is easy - just reorder the elements before the > elements. > > Regards, > Volker From volker.simonis at gmail.com Wed Oct 16 07:39:36 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Oct 2013 16:39:36 +0200 Subject: RFR(XS): 8026703 : Wrongly placed element in Event-Based JVM Tracing .xsl files In-Reply-To: References: Message-ID: Hi Keith, Staffan, thanks for the review. @Staffan: can you please push this. I think this should go right into hotspot-rt because it is not port relevant. Thanks, Volker On Wed, Oct 16, 2013 at 4:29 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 16 okt 2013, at 15:18, Volker Simonis wrote: > >> Hi, >> >> could somebody please review and push the following small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8026703/ >> https://bugs.openjdk.java.net/browse/JDK-8026703 >> >> Some background information: >> >> The three XSL files >> >> src/share/vm/trace/traceEventClasses.xsl >> src/share/vm/trace/traceEventIds.xsl >> src/share/vm/trace/traceTypes.xsl >> >> contain elements after elements. This is not >> allowed, because according to the XSLT specification >> (http://www.w3.org/TR/xslt#element-import) "xsl:import element >> children must precede all other element children of an xsl:stylesheet >> element". >> >> I do not know why the current OpenJDK XSLT processor doesn't object >> this (and maybe this should be the topic of another Bug/RFE), but >> other XSLT processors (i.e. the one in IBM J9) do care and this leads >> to build failures if building with a non-Oracle boot JDK. >> >> The fix is easy - just reorder the elements before the >> elements. >> >> Regards, >> Volker > From stefan.karlsson at oracle.com Wed Oct 16 08:22:14 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Oct 2013 17:22:14 +0200 Subject: Review request: 8026715: Remove the MetaDataDeallocateALot develop flag Message-ID: <525EAF26.8070108@oracle.com> http://cr.openjdk.java.net/~stefank/8026715/webrev.00/ Remove the MetaDataDeallocateALot develop flag (and code) that was added during the permgen removal. The code containes a number of bugs and crashes the VM when used. thanks, StefanK From coleen.phillimore at oracle.com Wed Oct 16 08:26:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Oct 2013 11:26:25 -0400 Subject: Review request: 8026715: Remove the MetaDataDeallocateALot develop flag In-Reply-To: <525EAF26.8070108@oracle.com> References: <525EAF26.8070108@oracle.com> Message-ID: <525EB021.1000106@oracle.com> Thank you!! I think this code was subject to a lot of bit rot because after initial development, it wasn't well used. Coleen On 10/16/2013 11:22 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8026715/webrev.00/ > > Remove the MetaDataDeallocateALot develop flag (and code) that was > added during the permgen removal. The code containes a number of bugs > and crashes the VM when used. > > thanks, > StefanK From erik.helin at oracle.com Wed Oct 16 09:09:14 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Oct 2013 18:09:14 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Message-ID: <20131016160914.GA10865@ehelin-thinkpad> Hi all, this patch fixes an issue where an oop in JvmtiBreakpoint, JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. Instead of registering the oop as an unhandled oop, which would have worked, I decided to wrap the oop in a handle as long as it is on the stack. A JvmtiBreakpoint is created on the stack by the two methods JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This JvmtiBreakpoint is only created to carry the Method*, jlocation and oop to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy the values from the stack allocated JvmtiBreakpoint and then place/clear the newly alloacted JvmtiBreakpoint in JvmtiCurrentBreakpoints::_jvmti_breakpoints. I have updated to the code to check that the public constructor is only used to allocate JvmtiBreakpoints on the stack (to warn a future programmer if he/she decides to allocate one on the heap). The class_loader oop is now wrapped in a Handle for stack allocated JvmtiBreakpoints. Due to the stack allocated JvmtiBreakpoint having the oop in a handle, the oops_do method of VM_ChangeBreakpoints can be removed. This also makes the oop in the handle safe for use after the VM_ChangeBreakpoint operation is finished. The unhandled oop in the JvmtiBreakpoint allocated on the heap will be visited by the GC via jvmtiExport::oops_do -> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being added to. I've also removed some dead code to simplify the change: - GrowableCache::insert - JvmtiBreakpoint::copy - JvmtiBreakpoint::lessThan - GrowableElement::lessThan Finally, I also formatted JvmtiEnv::ClearBreakpoint and Jvmti::SetBreakpoint exactly the same to highlight that they share all code except one line. Unfortunately, I was not able to remove this code duplication in a good way. Webrev: http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ Testing: - JPRT - The four tests that were failing are now passing Thanks, Erik From jaroslav.bachorik at oracle.com Wed Oct 16 09:16:15 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Oct 2013 18:16:15 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525CE56D.4000708@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> Message-ID: <525EBBCF.3020303@oracle.com> On 15.10.2013 08:49, David Holmes wrote: > Hi Jaroslav, > > os_bsd.cpp / os_linux.cpp: > > If you don't have a monotonic clock you leave timer_frequency set to 0! > (So you need to test on a system without a monotonic clock, or else > force it to act as-if not present.) > > That aside I don't trust clock_getres to give values that actually allow > the timer frequency to be determined. As per the comments in os_linux.cpp: > > // It's fixed in newer kernels, however clock_getres() still returns > // 1/HZ. We check if clock_getres() works, but will ignore its reported > // resolution for now. Hopefully as people move to new kernels, this > // won't be a problem. > > we don't know what kernels provide real values here and which provide > dummy ones. > > On BSD you haven't modified os::elapsed_counter. > > Looking at the linux changes I don't think the logic is correct even if > clock_getres is accurate. In the existing code we have: > > elapsed_counter -> elapsed time in microseconds > elapsed_frequency -> 1000 * 1000 (ie micros per second) > elapsed_time -> elapsed_counter*0.000001 -> time in seconds > > Now we have: > > elapsed_counter -> elapsed time in nanoseconds > elapsed_frequency -> 1x10^9 / whatever clock_getres says > elapsed_time -> counter/frequency -> ??? > > So elapsed_time not, in general, going to give the elapsed time in > seconds. And elapsed_time is not dependent on the "frequency" at all > because elapsed_counter is not reporting ticks but an actual elapsed > "time" in nanoseconds. > > > Also note that we constants for: > > NANOSECS_PER_SEC > NANOSECS_PER_MILLISEC > > to aid with time conversions. > > The linux webrev contains unrelated UseLargePages changes! Sorry for the mess with UseLargePages changes :/ I've fixed the problems with the frequency (using a fixed number as before) and I kept the changes to minimum. I was hesitating about changing the elapsed_counter precision from microseconds to nanoseconds but since solaris and windows versions already use nanosecond ticks for elapsed_counter I think the change is safe. The update webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > > > David > ----- > > > On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >> On 10.10.2013 13:15, Staffan Larsen wrote: >>> >>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>> wrote: >>> >>>> On 10.10.2013 05:44, David Holmes wrote: >>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>> >>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>> >>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>> the >>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>> os::elapsed_counter(). >>>>>>>> >>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>> >>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>> Management::timestamp(). >>>>>>> >>>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>>> I'm not sure which other parts could for whatever reason break once >>>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>> >>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>> current >>>>>>> phase of JDK release cycle? I think I could improve the patch in few >>>>>>> days and then it should probably be able to pass the review before >>>>>>> ZBB. But, it's only P3 ... >>>>>> >>>>>> I think it is a bit late in the release cycle to clean this up in the >>>>>> way it should be cleaned up. I think we should wait until the first 8 >>>>>> update release and do a more thorough job than we have time for right >>>>>> now. >>>>> >>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>> implementations are a tangled mess. But part of the problem has been >>>>> that people want/expect monotonic time-of-day based timestamps (yes a >>>>> contradiction - though some people make sure TOD does not get modified >>>>> on their production systems). The use of timestamps in logging has >>>>> to be >>>>> examined carefully - mainly GC logging. I recall a "simple" attempted >>>>> change in the past that resulted in trying to compare a nanoTime based >>>>> timestamp with the TOD. :( >>>> >>>> Actually, if I'm reading the sources right for Solaris and Win the >>>> monotonic clock source is used to provide elapsed_counter() value. It >>>> falls back to TOD when the monotonic clock source is not available. >>>> For Linux/BSD the TOD is used directly. >>>> >>>> This makes me wonder if changing the linux/bsd implementation to >>>> follow the same logic would be really that disruptive. >>> >>> Good point. I would like a world where elapsed_counter is monotonic >>> (where possible). Still a bit scary this late in the release, but an >>> interesting experiment. >> >> The change is rather simple and tests ok. All the means to get a >> monotonic timestamp are already there and proved to work. The core tests >> in JPRT went fine. >> >> The updated webrev is at >> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >> >> -JB- >> >>> >>> /Staffan >>> >>> >>> >>> >>>> >>>> -JB- >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>> Jaroslav, >>>>>>>>>>>> >>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>> based on >>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>> changes of the >>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The >>>>>>>>>>>>> uptime >>>>>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>>>>> using a >>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>> >>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>> ticks. >>>>>>>>>>>>> It is >>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>> convertible to >>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>> making it >>>>>>>>>>>>> very >>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>> >>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>> not a >>>>>>>>>>>> monotonic clock source. >>>>>>>>>>> >>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>> >>>>>>>>>>> Is there any reason why a non monotonic clock source is used for >>>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>>> uses >>>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>> "gettimeofday" >>>>>>>>>>> is not really a counter? >>>>>>>>>> >>>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>>> make me >>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>> because of >>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>> to be >>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>> >>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>>> can then >>>>>>>>>> be used for the uptime. >>>>>>>>> >>>>>>>>> My attempt at this is at >>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>> >>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>>>>>>> uptime in >>>>>>>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>>>>>>> >>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>>> bridging >>>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>>> constant >>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>>> order to >>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>> >>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> From mikael.gerdin at oracle.com Wed Oct 16 10:25:13 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Oct 2013 19:25:13 +0200 Subject: Review request: 8026715: Remove the MetaDataDeallocateALot develop flag In-Reply-To: <525EAF26.8070108@oracle.com> References: <525EAF26.8070108@oracle.com> Message-ID: <525ECBF9.1090803@oracle.com> Stefan, On 2013-10-16 17:22, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8026715/webrev.00/ globals.hpp: No comments. metaspace.cpp: Please remove the following comment as well 55 // Parameters for stress mode testing Otherwise the change looks good. /Mikael > > Remove the MetaDataDeallocateALot develop flag (and code) that was added > during the permgen removal. The code containes a number of bugs and > crashes the VM when used. > > thanks, > StefanK From mikael.gerdin at oracle.com Wed Oct 16 10:26:08 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Oct 2013 19:26:08 +0200 Subject: Review request: 8026707: JDK-8026391 broke the optimized build target In-Reply-To: <525EA039.7050004@oracle.com> References: <525EA039.7050004@oracle.com> Message-ID: <525ECC30.3090102@oracle.com> Stefan, On 2013-10-16 16:18, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8026707/webrev.00/ The change looks good. /Mikael > > Metachunk::mangle() was incorrectly moved being guarded by NOT_PRODUCT() > to being guarded by ASSERT. The patch reverts that change. > > thanks, > StefanK From coleen.phillimore at oracle.com Wed Oct 16 10:25:50 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Oct 2013 13:25:50 -0400 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131016160914.GA10865@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> Message-ID: <525ECC1E.4000805@oracle.com> Erik, Thank you for doing the extra cleanup for this. Did you run the nsk.jvmti.testlist tests too though? These things have a nasty way of interacting. The code looks good though. thanks, Coleen On 10/16/2013 12:09 PM, Erik Helin wrote: > Hi all, > > this patch fixes an issue where an oop in JvmtiBreakpoint, > JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > Instead of registering the oop as an unhandled oop, which would have > worked, I decided to wrap the oop in a handle as long as it is on the > stack. > > A JvmtiBreakpoint is created on the stack by the two methods > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > the values from the stack allocated JvmtiBreakpoint and then place/clear the > newly alloacted JvmtiBreakpoint in > JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > I have updated to the code to check that the public constructor is only > used to allocate JvmtiBreakpoints on the stack (to warn a future > programmer if he/she decides to allocate one on the heap). The > class_loader oop is now wrapped in a Handle for stack allocated > JvmtiBreakpoints. > > Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > the oops_do method of VM_ChangeBreakpoints can be removed. This also > makes the oop in the handle safe for use after the VM_ChangeBreakpoint > operation is finished. > > The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > visited by the GC via jvmtiExport::oops_do -> > JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > added to. > > I've also removed some dead code to simplify the change: > - GrowableCache::insert > - JvmtiBreakpoint::copy > - JvmtiBreakpoint::lessThan > - GrowableElement::lessThan > > Finally, I also formatted JvmtiEnv::ClearBreakpoint and > Jvmti::SetBreakpoint exactly the same to highlight that they share all > code except one line. Unfortunately, I was not able to remove this code > duplication in a good way. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > Testing: > - JPRT > - The four tests that were failing are now passing > > Thanks, > Erik From stefan.karlsson at oracle.com Wed Oct 16 10:39:01 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Oct 2013 19:39:01 +0200 Subject: Review request: 8026715: Remove the MetaDataDeallocateALot develop flag In-Reply-To: <525EB021.1000106@oracle.com> References: <525EAF26.8070108@oracle.com> <525EB021.1000106@oracle.com> Message-ID: <525ECF35.3010004@oracle.com> On 10/16/13 5:26 PM, Coleen Phillimore wrote: > > Thank you!! I think this code was subject to a lot of bit rot because > after initial development, it wasn't well used. I agree. thanks, StefanK > Coleen > > On 10/16/2013 11:22 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8026715/webrev.00/ >> >> Remove the MetaDataDeallocateALot develop flag (and code) that was >> added during the permgen removal. The code containes a number of bugs >> and crashes the VM when used. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Oct 16 10:39:25 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Oct 2013 19:39:25 +0200 Subject: Review request: 8026715: Remove the MetaDataDeallocateALot develop flag In-Reply-To: <525ECBF9.1090803@oracle.com> References: <525EAF26.8070108@oracle.com> <525ECBF9.1090803@oracle.com> Message-ID: <525ECF4D.3030107@oracle.com> On 10/16/13 7:25 PM, Mikael Gerdin wrote: > Stefan, > > On 2013-10-16 17:22, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8026715/webrev.00/ > > globals.hpp: > No comments. > > metaspace.cpp: > Please remove the following comment as well > 55 // Parameters for stress mode testing Will do. > > Otherwise the change looks good. thanks, StefanK > > /Mikael > > >> >> Remove the MetaDataDeallocateALot develop flag (and code) that was added >> during the permgen removal. The code containes a number of bugs and >> crashes the VM when used. >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Oct 16 10:39:48 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Oct 2013 19:39:48 +0200 Subject: Review request: 8026707: JDK-8026391 broke the optimized build target In-Reply-To: <525ECC30.3090102@oracle.com> References: <525EA039.7050004@oracle.com> <525ECC30.3090102@oracle.com> Message-ID: <525ECF64.9050904@oracle.com> On 10/16/13 7:26 PM, Mikael Gerdin wrote: > Stefan, > > On 2013-10-16 16:18, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8026707/webrev.00/ > > The change looks good. Thanks, Mikael. StefanK > > /Mikael > >> >> Metachunk::mangle() was incorrectly moved being guarded by NOT_PRODUCT() >> to being guarded by ASSERT. The patch reverts that change. >> >> thanks, >> StefanK > From coleen.phillimore at oracle.com Wed Oct 16 10:34:03 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Oct 2013 13:34:03 -0400 Subject: Review request: 8026707: JDK-8026391 broke the optimized build target In-Reply-To: <525ECF64.9050904@oracle.com> References: <525EA039.7050004@oracle.com> <525ECC30.3090102@oracle.com> <525ECF64.9050904@oracle.com> Message-ID: <525ECE0B.2060703@oracle.com> +1. Coleen On 10/16/2013 01:39 PM, Stefan Karlsson wrote: > On 10/16/13 7:26 PM, Mikael Gerdin wrote: >> Stefan, >> >> On 2013-10-16 16:18, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8026707/webrev.00/ >> >> The change looks good. > > Thanks, Mikael. > > StefanK >> >> /Mikael >> >>> >>> Metachunk::mangle() was incorrectly moved being guarded by >>> NOT_PRODUCT() >>> to being guarded by ASSERT. The patch reverts that change. >>> >>> thanks, >>> StefanK >> > From mikael.gerdin at oracle.com Wed Oct 16 10:47:36 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Oct 2013 19:47:36 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131016160914.GA10865@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> Message-ID: <525ED138.1000305@oracle.com> Erik, (it's not necessary to cross-post between hotspot-dev and hotspot-gc-dev, so I removed hotspot-gc from the CC list) On 2013-10-16 18:09, Erik Helin wrote: > Hi all, > > this patch fixes an issue where an oop in JvmtiBreakpoint, > JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > Instead of registering the oop as an unhandled oop, which would have > worked, I decided to wrap the oop in a handle as long as it is on the > stack. > > A JvmtiBreakpoint is created on the stack by the two methods > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > the values from the stack allocated JvmtiBreakpoint and then place/clear the > newly alloacted JvmtiBreakpoint in > JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > I have updated to the code to check that the public constructor is only > used to allocate JvmtiBreakpoints on the stack (to warn a future > programmer if he/she decides to allocate one on the heap). The > class_loader oop is now wrapped in a Handle for stack allocated > JvmtiBreakpoints. > > Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > the oops_do method of VM_ChangeBreakpoints can be removed. This also > makes the oop in the handle safe for use after the VM_ChangeBreakpoint > operation is finished. > > The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > visited by the GC via jvmtiExport::oops_do -> > JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > added to. > > I've also removed some dead code to simplify the change: > - GrowableCache::insert > - JvmtiBreakpoint::copy > - JvmtiBreakpoint::lessThan > - GrowableElement::lessThan > > Finally, I also formatted JvmtiEnv::ClearBreakpoint and > Jvmti::SetBreakpoint exactly the same to highlight that they share all > code except one line. Unfortunately, I was not able to remove this code > duplication in a good way. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ jvmtiImpl.hpp: Since clone() uses unhandled oops, and is only supposed to be used by the VM operation, would it make sense to assert(SafepointSynchronize::is_at_safepoint())? 196 GrowableElement *clone() { 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); jvmtiImpl.cpp: No comments. jvmtiEnv.cpp: Have you verified that the generated JVMTI entry point contains a ResourceMark or is it just not needed? - ResourceMark rm; + HandleMark hm; Otherwise the code change looks good. One thing that you didn't describe here, but which was related to the bug (which we discussed) was the fact that the old code tried to "do the right thing" WRT CheckUnhandledOops, but it incorrectly added a Method*: thread->allow_unhandled_oop((oop*)&_method); We should take care to find other such places where we try to put a non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in the unhandled oops code. /Mikael > > Testing: > - JPRT > - The four tests that were failing are now passing > > Thanks, > Erik > From jon.masamitsu at oracle.com Wed Oct 16 11:55:46 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Oct 2013 11:55:46 -0700 Subject: Review request: 8026707: JDK-8026391 broke the optimized build target In-Reply-To: <525EA039.7050004@oracle.com> References: <525EA039.7050004@oracle.com> Message-ID: <525EE132.1040707@oracle.com> Looks good. Jon On 10/16/13 7:18 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8026707/webrev.00/ > > Metachunk::mangle() was incorrectly moved being guarded by > NOT_PRODUCT() to being guarded by ASSERT. The patch reverts that change. > > thanks, > StefanK From serguei.spitsyn at oracle.com Wed Oct 16 12:14:06 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 16 Oct 2013 12:14:06 -0700 Subject: RFR(XS): 8026703 : Wrongly placed element in Event-Based JVM Tracing .xsl files In-Reply-To: References: Message-ID: <525EE57E.1030401@oracle.com> It looks good. Thanks, Serguei On 10/16/13 6:18 AM, Volker Simonis wrote: > Hi, > > could somebody please review and push the following small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/8026703/ > https://bugs.openjdk.java.net/browse/JDK-8026703 > > Some background information: > > The three XSL files > > src/share/vm/trace/traceEventClasses.xsl > src/share/vm/trace/traceEventIds.xsl > src/share/vm/trace/traceTypes.xsl > > contain elements after elements. This is not > allowed, because according to the XSLT specification > (http://www.w3.org/TR/xslt#element-import) "xsl:import element > children must precede all other element children of an xsl:stylesheet > element". > > I do not know why the current OpenJDK XSLT processor doesn't object > this (and maybe this should be the topic of another Bug/RFE), but > other XSLT processors (i.e. the one in IBM J9) do care and this leads > to build failures if building with a non-Oracle boot JDK. > > The fix is easy - just reorder the elements before the > elements. > > Regards, > Volker From stefan.karlsson at oracle.com Wed Oct 16 12:22:43 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Oct 2013 21:22:43 +0200 Subject: Review request: 8026707: JDK-8026391 broke the optimized build target In-Reply-To: <525EE132.1040707@oracle.com> References: <525EA039.7050004@oracle.com> <525EE132.1040707@oracle.com> Message-ID: <525EE783.5040101@oracle.com> On 10/16/13 8:55 PM, Jon Masamitsu wrote: > Looks good. Thanks, Jon. StefanK > > Jon > > On 10/16/13 7:18 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8026707/webrev.00/ >> >> Metachunk::mangle() was incorrectly moved being guarded by >> NOT_PRODUCT() to being guarded by ASSERT. The patch reverts that change. >> >> thanks, >> StefanK > From magnus.ihse.bursie at oracle.com Tue Oct 15 05:07:22 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Oct 2013 14:07:22 +0200 Subject: RFR: JDK-8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. In-Reply-To: <525BB895.3020906@oracle.com> References: <525BB895.3020906@oracle.com> Message-ID: <525D2FFA.208@oracle.com> On 2013-10-14 11:25, Erik Joelsson wrote: > Please review the following changes, correcting the conditions for > when to build certain parts of the servicability features. Instead of > guarding them with the OPENJDK variable, they need to be conditioned > on the existence of the source itself. > > In hotspot, this only fails on Windows. The linux makefiles already > check on the existence of the source rather than if it's an OPENJDK > build. This change makes windows do the same. > > http://cr.openjdk.java.net/~erikj/8019540/webrev.hotspot.01/ > > In JDK, it fails on all platforms. There is already a configure > variable, ENABLE_JFR, that seems to be set correctly for this case. > > http://cr.openjdk.java.net/~erikj/8019540/webrev.jdk.01/ Looks good (but nmake syntax is possibly even worse than normal make :)) /Magnus From yekaterina.kantserova at oracle.com Wed Oct 16 01:06:12 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 16 Oct 2013 10:06:12 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525E10D2.2060604@oracle.com> References: <525D4490.3070506@oracle.com> <525E10D2.2060604@oracle.com> Message-ID: <525E48F4.9000001@oracle.com> Hi David, Thank you for your comments! You have right, it's worth to check testlibrary changes twice. For example Erik Helin has pointed out to me there already is Asserts.java in hotspot/testlibrary. I don't mind to merge hotspot testlibrary into jdk. Thanks, Katja On 10/16/2013 06:06 AM, David Holmes wrote: > Hi Katja, > > Not a review just a couple of meta comments. > > First I've added hotspto-dev as all these changes to the test library > need a wider review audience. I'm a little concerned about its current > rate of expansion. > > Second all the new files have the wrong copyright notice - they should > have the OpenJDK copyright. > > Thanks, > David > > On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> The purpose of this fix is to get rid of intermittent failures in >> sun/tools/jstatd tests and make the tests more stable, legible and >> maintainable. >> >> Thanks, >> Katja >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 From calvin.cheung at oracle.com Wed Oct 16 16:41:29 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Wed, 16 Oct 2013 23:41:29 +0000 Subject: hg: hsx/hotspot-main/hotspot: 16 new changesets Message-ID: <20131016234204.1970A62494@hg.openjdk.java.net> Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e831448418ac Merge Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/301ece1880ad Merge Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/26ae62bc26c4 Merge Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df268195b0ea Merge Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/83dbf427fedd Merge Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8703d708e6e Merge From daniel.daugherty at oracle.com Wed Oct 16 16:54:16 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 16 Oct 2013 23:54:16 +0000 Subject: hg: hsx/hotspot-main: 7165611: implement Full Debug Symbols on MacOS X hotspot Message-ID: <20131016235416.6F00B62495@hg.openjdk.java.net> Changeset: 22c6f0b7e2b5 Author: dcubed Date: 2013-10-15 08:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/22c6f0b7e2b5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk From daniel.daugherty at oracle.com Wed Oct 16 16:56:27 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 16 Oct 2013 23:56:27 +0000 Subject: hg: hsx/hotspot-main/jdk: 7165611: implement Full Debug Symbols on MacOS X hotspot Message-ID: <20131016235807.47E2E62496@hg.openjdk.java.net> Changeset: 01b81253f2d5 Author: dcubed Date: 2013-10-15 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01b81253f2d5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/common/Defs-macosx.gmk ! make/common/Defs.gmk ! make/java/redist/Makefile ! makefiles/Import.gmk ! makefiles/Tools.gmk From david.holmes at oracle.com Wed Oct 16 19:26:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 12:26:40 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525EBBCF.3020303@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> Message-ID: <525F4AE0.1000406@oracle.com> Hi Jaroslav, Minor nit: os::elapsed_time should really be defined in terms of the other functions ie: return ((double) os::elapsed_counter()) / os::elapsed_frequency(); I also prefer the cast above as it is very clear that we will be doing a floating-point division. Aside: AFAICS os::elapsed_time() is never actually used ?? I agree that it appears that changing the frequency should be okay. Thanks, David On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: > On 15.10.2013 08:49, David Holmes wrote: >> Hi Jaroslav, >> >> os_bsd.cpp / os_linux.cpp: >> >> If you don't have a monotonic clock you leave timer_frequency set to 0! >> (So you need to test on a system without a monotonic clock, or else >> force it to act as-if not present.) >> >> That aside I don't trust clock_getres to give values that actually allow >> the timer frequency to be determined. As per the comments in >> os_linux.cpp: >> >> // It's fixed in newer kernels, however clock_getres() still returns >> // 1/HZ. We check if clock_getres() works, but will ignore its reported >> // resolution for now. Hopefully as people move to new kernels, this >> // won't be a problem. >> >> we don't know what kernels provide real values here and which provide >> dummy ones. >> >> On BSD you haven't modified os::elapsed_counter. >> >> Looking at the linux changes I don't think the logic is correct even if >> clock_getres is accurate. In the existing code we have: >> >> elapsed_counter -> elapsed time in microseconds >> elapsed_frequency -> 1000 * 1000 (ie micros per second) >> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >> >> Now we have: >> >> elapsed_counter -> elapsed time in nanoseconds >> elapsed_frequency -> 1x10^9 / whatever clock_getres says >> elapsed_time -> counter/frequency -> ??? >> >> So elapsed_time not, in general, going to give the elapsed time in >> seconds. And elapsed_time is not dependent on the "frequency" at all >> because elapsed_counter is not reporting ticks but an actual elapsed >> "time" in nanoseconds. >> >> >> Also note that we constants for: >> >> NANOSECS_PER_SEC >> NANOSECS_PER_MILLISEC >> >> to aid with time conversions. >> >> The linux webrev contains unrelated UseLargePages changes! > > Sorry for the mess with UseLargePages changes :/ > > I've fixed the problems with the frequency (using a fixed number as > before) and I kept the changes to minimum. > > I was hesitating about changing the elapsed_counter precision from > microseconds to nanoseconds but since solaris and windows versions > already use nanosecond ticks for elapsed_counter I think the change is > safe. > > The update webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > >> >> >> David >> ----- >> >> >> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>> >>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>> wrote: >>>> >>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>> >>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>> >>>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>>> the >>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>> os::elapsed_counter(). >>>>>>>>> >>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>>> >>>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>>> Management::timestamp(). >>>>>>>> >>>>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>>>> I'm not sure which other parts could for whatever reason break once >>>>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>> >>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>> current >>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>> few >>>>>>>> days and then it should probably be able to pass the review before >>>>>>>> ZBB. But, it's only P3 ... >>>>>>> >>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>> the >>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>> first 8 >>>>>>> update release and do a more thorough job than we have time for >>>>>>> right >>>>>>> now. >>>>>> >>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>> implementations are a tangled mess. But part of the problem has been >>>>>> that people want/expect monotonic time-of-day based timestamps (yes a >>>>>> contradiction - though some people make sure TOD does not get >>>>>> modified >>>>>> on their production systems). The use of timestamps in logging has >>>>>> to be >>>>>> examined carefully - mainly GC logging. I recall a "simple" attempted >>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>> based >>>>>> timestamp with the TOD. :( >>>>> >>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>> monotonic clock source is used to provide elapsed_counter() value. It >>>>> falls back to TOD when the monotonic clock source is not available. >>>>> For Linux/BSD the TOD is used directly. >>>>> >>>>> This makes me wonder if changing the linux/bsd implementation to >>>>> follow the same logic would be really that disruptive. >>>> >>>> Good point. I would like a world where elapsed_counter is monotonic >>>> (where possible). Still a bit scary this late in the release, but an >>>> interesting experiment. >>> >>> The change is rather simple and tests ok. All the means to get a >>> monotonic timestamp are already there and proved to work. The core tests >>> in JPRT went fine. >>> >>> The updated webrev is at >>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>> >>> -JB- >>> >>>> >>>> /Staffan >>>> >>>> >>>> >>>> >>>>> >>>>> -JB- >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>> based on >>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>> The >>>>>>>>>>>>>> uptime >>>>>>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>>>>>> using a >>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>> It is >>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>> making it >>>>>>>>>>>>>> very >>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>>> not a >>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>> >>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>> >>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>> for >>>>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>>>> uses >>>>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>> is not really a counter? >>>>>>>>>>> >>>>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>>>> make me >>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>> because of >>>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>>> to be >>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>> >>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>>>> can then >>>>>>>>>>> be used for the uptime. >>>>>>>>>> >>>>>>>>>> My attempt at this is at >>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>>> possible. >>>>>>>>>> >>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>> the >>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>>>> bridging >>>>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>>>> constant >>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>>>> order to >>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> > From jaroslav.bachorik at oracle.com Thu Oct 17 03:10:39 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 17 Oct 2013 12:10:39 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525F4AE0.1000406@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> Message-ID: <525FB79F.7070101@oracle.com> Hi David, On 17.10.2013 04:26, David Holmes wrote: > Hi Jaroslav, > > Minor nit: os::elapsed_time should really be defined in terms of the > other functions ie: > > return ((double) os::elapsed_counter()) / os::elapsed_frequency(); Ok. I've changed it. It better communicates the way the elapsedTime is calculated anyway. > > I also prefer the cast above as it is very clear that we will be doing a > floating-point division. > > Aside: AFAICS os::elapsed_time() is never actually used ?? Actually, it is os::elapsedTime() and this one is used quite a lot. The "elapsed_time()" form is used only in bytecodeHistogram.hpp, parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. > > I agree that it appears that changing the frequency should be okay. Thanks for the feedback. Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 -JB- > > Thanks, > David > > On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >> On 15.10.2013 08:49, David Holmes wrote: >>> Hi Jaroslav, >>> >>> os_bsd.cpp / os_linux.cpp: >>> >>> If you don't have a monotonic clock you leave timer_frequency set to 0! >>> (So you need to test on a system without a monotonic clock, or else >>> force it to act as-if not present.) >>> >>> That aside I don't trust clock_getres to give values that actually allow >>> the timer frequency to be determined. As per the comments in >>> os_linux.cpp: >>> >>> // It's fixed in newer kernels, however clock_getres() still returns >>> // 1/HZ. We check if clock_getres() works, but will ignore its reported >>> // resolution for now. Hopefully as people move to new kernels, this >>> // won't be a problem. >>> >>> we don't know what kernels provide real values here and which provide >>> dummy ones. >>> >>> On BSD you haven't modified os::elapsed_counter. >>> >>> Looking at the linux changes I don't think the logic is correct even if >>> clock_getres is accurate. In the existing code we have: >>> >>> elapsed_counter -> elapsed time in microseconds >>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>> >>> Now we have: >>> >>> elapsed_counter -> elapsed time in nanoseconds >>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>> elapsed_time -> counter/frequency -> ??? >>> >>> So elapsed_time not, in general, going to give the elapsed time in >>> seconds. And elapsed_time is not dependent on the "frequency" at all >>> because elapsed_counter is not reporting ticks but an actual elapsed >>> "time" in nanoseconds. >>> >>> >>> Also note that we constants for: >>> >>> NANOSECS_PER_SEC >>> NANOSECS_PER_MILLISEC >>> >>> to aid with time conversions. >>> >>> The linux webrev contains unrelated UseLargePages changes! >> >> Sorry for the mess with UseLargePages changes :/ >> >> I've fixed the problems with the frequency (using a fixed number as >> before) and I kept the changes to minimum. >> >> I was hesitating about changing the elapsed_counter precision from >> microseconds to nanoseconds but since solaris and windows versions >> already use nanosecond ticks for elapsed_counter I think the change is >> safe. >> >> The update webrev: >> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >> >>> >>> >>> David >>> ----- >>> >>> >>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>> >>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>> >>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>> >>>>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>>>> the >>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>> os::elapsed_counter(). >>>>>>>>>> >>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>>>> >>>>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>>>> Management::timestamp(). >>>>>>>>> >>>>>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>> once >>>>>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>> >>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>> current >>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>> few >>>>>>>>> days and then it should probably be able to pass the review before >>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>> >>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>> the >>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>> first 8 >>>>>>>> update release and do a more thorough job than we have time for >>>>>>>> right >>>>>>>> now. >>>>>>> >>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>> implementations are a tangled mess. But part of the problem has been >>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>> (yes a >>>>>>> contradiction - though some people make sure TOD does not get >>>>>>> modified >>>>>>> on their production systems). The use of timestamps in logging has >>>>>>> to be >>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>> attempted >>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>> based >>>>>>> timestamp with the TOD. :( >>>>>> >>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>> monotonic clock source is used to provide elapsed_counter() value. It >>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>> For Linux/BSD the TOD is used directly. >>>>>> >>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>> follow the same logic would be really that disruptive. >>>>> >>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>> (where possible). Still a bit scary this late in the release, but an >>>>> interesting experiment. >>>> >>>> The change is rather simple and tests ok. All the means to get a >>>> monotonic timestamp are already there and proved to work. The core >>>> tests >>>> in JPRT went fine. >>>> >>>> The updated webrev is at >>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>> >>>> -JB- >>>> >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> -JB- >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>> The >>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>> very >>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>>>> not a >>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>> >>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>> for >>>>>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>>>>> uses >>>>>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>> >>>>>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>>>>> make me >>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>> because of >>>>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>>>> to be >>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>>>>> can then >>>>>>>>>>>> be used for the uptime. >>>>>>>>>>> >>>>>>>>>>> My attempt at this is at >>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From david.holmes at oracle.com Thu Oct 17 04:07:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 21:07:36 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FB79F.7070101@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> Message-ID: <525FC4F8.1020004@oracle.com> On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: > Hi David, > > On 17.10.2013 04:26, David Holmes wrote: >> Hi Jaroslav, >> >> Minor nit: os::elapsed_time should really be defined in terms of the >> other functions ie: >> >> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); > > Ok. I've changed it. It better communicates the way the elapsedTime is > calculated anyway. > >> >> I also prefer the cast above as it is very clear that we will be doing a >> floating-point division. >> >> Aside: AFAICS os::elapsed_time() is never actually used ?? > > Actually, it is os::elapsedTime() and this one is used quite a lot. The > "elapsed_time()" form is used only in bytecodeHistogram.hpp, > parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. AFAICS they all define their own elapsed_time() functions they don't use os::elapsed_time(). >> >> I agree that it appears that changing the frequency should be okay. > > Thanks for the feedback. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 That should be .04 version :) Looks okay. Thanks, David > -JB- > >> >> Thanks, >> David >> >> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>> On 15.10.2013 08:49, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> os_bsd.cpp / os_linux.cpp: >>>> >>>> If you don't have a monotonic clock you leave timer_frequency set to 0! >>>> (So you need to test on a system without a monotonic clock, or else >>>> force it to act as-if not present.) >>>> >>>> That aside I don't trust clock_getres to give values that actually >>>> allow >>>> the timer frequency to be determined. As per the comments in >>>> os_linux.cpp: >>>> >>>> // It's fixed in newer kernels, however clock_getres() still returns >>>> // 1/HZ. We check if clock_getres() works, but will ignore its reported >>>> // resolution for now. Hopefully as people move to new kernels, this >>>> // won't be a problem. >>>> >>>> we don't know what kernels provide real values here and which provide >>>> dummy ones. >>>> >>>> On BSD you haven't modified os::elapsed_counter. >>>> >>>> Looking at the linux changes I don't think the logic is correct even if >>>> clock_getres is accurate. In the existing code we have: >>>> >>>> elapsed_counter -> elapsed time in microseconds >>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>> >>>> Now we have: >>>> >>>> elapsed_counter -> elapsed time in nanoseconds >>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>> elapsed_time -> counter/frequency -> ??? >>>> >>>> So elapsed_time not, in general, going to give the elapsed time in >>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>> "time" in nanoseconds. >>>> >>>> >>>> Also note that we constants for: >>>> >>>> NANOSECS_PER_SEC >>>> NANOSECS_PER_MILLISEC >>>> >>>> to aid with time conversions. >>>> >>>> The linux webrev contains unrelated UseLargePages changes! >>> >>> Sorry for the mess with UseLargePages changes :/ >>> >>> I've fixed the problems with the frequency (using a fixed number as >>> before) and I kept the changes to minimum. >>> >>> I was hesitating about changing the elapsed_counter precision from >>> microseconds to nanoseconds but since solaris and windows versions >>> already use nanosecond ticks for elapsed_counter I think the change is >>> safe. >>> >>> The update webrev: >>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>> >>>> >>>> >>>> David >>>> ----- >>>> >>>> >>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>> >>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>> >>>>>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>>>>> the >>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>> >>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>>>>> >>>>>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>>>>> Management::timestamp(). >>>>>>>>>> >>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>> honestly, >>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>> once >>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>> equivalent. >>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>> >>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>> current >>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>> few >>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>> before >>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>> >>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>> the >>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>> first 8 >>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>> right >>>>>>>>> now. >>>>>>>> >>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>> been >>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>> (yes a >>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>> modified >>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>> to be >>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>> attempted >>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>> based >>>>>>>> timestamp with the TOD. :( >>>>>>> >>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>> value. It >>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>> For Linux/BSD the TOD is used directly. >>>>>>> >>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>> follow the same logic would be really that disruptive. >>>>>> >>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>> interesting experiment. >>>>> >>>>> The change is rather simple and tests ok. All the means to get a >>>>> monotonic timestamp are already there and proved to work. The core >>>>> tests >>>>> in JPRT went fine. >>>>> >>>>> The updated webrev is at >>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>> for >>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>> uses >>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>> for >>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>> >>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>> make me >>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>> because of >>>>>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>>>>> to be >>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>> that >>>>>>>>>>>>> can then >>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>> >>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Oct 17 04:13:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 21:13:49 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FC4F8.1020004@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> <525FC4F8.1020004@oracle.com> Message-ID: <525FC66D.9040602@oracle.com> On 17/10/2013 9:07 PM, David Holmes wrote: > On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: >> Hi David, >> >> On 17.10.2013 04:26, David Holmes wrote: >>> Hi Jaroslav, >>> >>> Minor nit: os::elapsed_time should really be defined in terms of the >>> other functions ie: >>> >>> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); >> >> Ok. I've changed it. It better communicates the way the elapsedTime is >> calculated anyway. >> >>> >>> I also prefer the cast above as it is very clear that we will be doing a >>> floating-point division. >>> >>> Aside: AFAICS os::elapsed_time() is never actually used ?? >> >> Actually, it is os::elapsedTime() and this one is used quite a lot. The >> "elapsed_time()" form is used only in bytecodeHistogram.hpp, >> parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. > > AFAICS they all define their own elapsed_time() functions they don't use > os::elapsed_time(). Ooops! I mis-grepped. It is os::elapsedTime not os::elapsed_time Nothing like inconsistent naming :( David ----- >>> >>> I agree that it appears that changing the frequency should be okay. >> >> Thanks for the feedback. >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > > That should be .04 version :) > > Looks okay. > > Thanks, > David > >> -JB- >> >>> >>> Thanks, >>> David >>> >>> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>>> On 15.10.2013 08:49, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> os_bsd.cpp / os_linux.cpp: >>>>> >>>>> If you don't have a monotonic clock you leave timer_frequency set >>>>> to 0! >>>>> (So you need to test on a system without a monotonic clock, or else >>>>> force it to act as-if not present.) >>>>> >>>>> That aside I don't trust clock_getres to give values that actually >>>>> allow >>>>> the timer frequency to be determined. As per the comments in >>>>> os_linux.cpp: >>>>> >>>>> // It's fixed in newer kernels, however clock_getres() still returns >>>>> // 1/HZ. We check if clock_getres() works, but will ignore its >>>>> reported >>>>> // resolution for now. Hopefully as people move to new kernels, this >>>>> // won't be a problem. >>>>> >>>>> we don't know what kernels provide real values here and which provide >>>>> dummy ones. >>>>> >>>>> On BSD you haven't modified os::elapsed_counter. >>>>> >>>>> Looking at the linux changes I don't think the logic is correct >>>>> even if >>>>> clock_getres is accurate. In the existing code we have: >>>>> >>>>> elapsed_counter -> elapsed time in microseconds >>>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>>> >>>>> Now we have: >>>>> >>>>> elapsed_counter -> elapsed time in nanoseconds >>>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>>> elapsed_time -> counter/frequency -> ??? >>>>> >>>>> So elapsed_time not, in general, going to give the elapsed time in >>>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>>> "time" in nanoseconds. >>>>> >>>>> >>>>> Also note that we constants for: >>>>> >>>>> NANOSECS_PER_SEC >>>>> NANOSECS_PER_MILLISEC >>>>> >>>>> to aid with time conversions. >>>>> >>>>> The linux webrev contains unrelated UseLargePages changes! >>>> >>>> Sorry for the mess with UseLargePages changes :/ >>>> >>>> I've fixed the problems with the frequency (using a fixed number as >>>> before) and I kept the changes to minimum. >>>> >>>> I was hesitating about changing the elapsed_counter precision from >>>> microseconds to nanoseconds but since solaris and windows versions >>>> already use nanosecond ticks for elapsed_counter I think the change is >>>> safe. >>>> >>>> The update webrev: >>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>>> >>>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>>> >>>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>>> >>>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>>> >>>>>>>>>>>> This discussion also implies that the "elapsed time" we >>>>>>>>>>>> print in >>>>>>>>>>>> the >>>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>> >>>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>>> (class VMUptimeDCmd) which also relies on >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>> >>>>>>>>>>> Also the reported GC pauses duration might be wrong since it >>>>>>>>>>> uses >>>>>>>>>>> Management::timestamp(). >>>>>>>>>>> >>>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>>> honestly, >>>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>>> once >>>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>>> equivalent. >>>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>>> >>>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>>> current >>>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>>> few >>>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>>> before >>>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>>> >>>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>>> the >>>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>>> first 8 >>>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>>> right >>>>>>>>>> now. >>>>>>>>> >>>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>>> been >>>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>>> (yes a >>>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>>> modified >>>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>>> to be >>>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>>> attempted >>>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>>> based >>>>>>>>> timestamp with the TOD. :( >>>>>>>> >>>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>>> value. It >>>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>>> For Linux/BSD the TOD is used directly. >>>>>>>> >>>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>>> follow the same logic would be really that disruptive. >>>>>>> >>>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>>> interesting experiment. >>>>>> >>>>>> The change is rather simple and tests ok. All the means to get a >>>>>> monotonic timestamp are already there and proved to work. The core >>>>>> tests >>>>>> in JPRT went fine. >>>>>> >>>>>> The updated webrev is at >>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday >>>>>>>>>>>>>>>> so is >>>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>>> make me >>>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>>> because of >>>>>>>>>>>>>> the way these are used in logging etc. Certainly not >>>>>>>>>>>>>> something >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>>> that >>>>>>>>>>>>>> can then >>>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>>> >>>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>>> >>>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks >>>>>>>>>>>>> where >>>>>>>>>>>>> possible. >>>>>>>>>>>>> >>>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From jaroslav.bachorik at oracle.com Thu Oct 17 05:09:40 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 17 Oct 2013 14:09:40 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FC4F8.1020004@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> <525FC4F8.1020004@oracle.com> Message-ID: <525FD384.4010904@oracle.com> On 17.10.2013 13:07, David Holmes wrote: > On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: >> Hi David, >> >> On 17.10.2013 04:26, David Holmes wrote: >>> Hi Jaroslav, >>> >>> Minor nit: os::elapsed_time should really be defined in terms of the >>> other functions ie: >>> >>> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); >> >> Ok. I've changed it. It better communicates the way the elapsedTime is >> calculated anyway. >> >>> >>> I also prefer the cast above as it is very clear that we will be doing a >>> floating-point division. >>> >>> Aside: AFAICS os::elapsed_time() is never actually used ?? >> >> Actually, it is os::elapsedTime() and this one is used quite a lot. The >> "elapsed_time()" form is used only in bytecodeHistogram.hpp, >> parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. > > AFAICS they all define their own elapsed_time() functions they don't use > os::elapsed_time(). > >>> >>> I agree that it appears that changing the frequency should be okay. >> >> Thanks for the feedback. >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > > That should be .04 version :) Yep :( copy-paste ... http://cr.openjdk.java.net/~jbachorik/6523160/webrev.04 > > Looks okay. > > Thanks, > David > >> -JB- >> >>> >>> Thanks, >>> David >>> >>> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>>> On 15.10.2013 08:49, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> os_bsd.cpp / os_linux.cpp: >>>>> >>>>> If you don't have a monotonic clock you leave timer_frequency set >>>>> to 0! >>>>> (So you need to test on a system without a monotonic clock, or else >>>>> force it to act as-if not present.) >>>>> >>>>> That aside I don't trust clock_getres to give values that actually >>>>> allow >>>>> the timer frequency to be determined. As per the comments in >>>>> os_linux.cpp: >>>>> >>>>> // It's fixed in newer kernels, however clock_getres() still returns >>>>> // 1/HZ. We check if clock_getres() works, but will ignore its >>>>> reported >>>>> // resolution for now. Hopefully as people move to new kernels, this >>>>> // won't be a problem. >>>>> >>>>> we don't know what kernels provide real values here and which provide >>>>> dummy ones. >>>>> >>>>> On BSD you haven't modified os::elapsed_counter. >>>>> >>>>> Looking at the linux changes I don't think the logic is correct >>>>> even if >>>>> clock_getres is accurate. In the existing code we have: >>>>> >>>>> elapsed_counter -> elapsed time in microseconds >>>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>>> >>>>> Now we have: >>>>> >>>>> elapsed_counter -> elapsed time in nanoseconds >>>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>>> elapsed_time -> counter/frequency -> ??? >>>>> >>>>> So elapsed_time not, in general, going to give the elapsed time in >>>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>>> "time" in nanoseconds. >>>>> >>>>> >>>>> Also note that we constants for: >>>>> >>>>> NANOSECS_PER_SEC >>>>> NANOSECS_PER_MILLISEC >>>>> >>>>> to aid with time conversions. >>>>> >>>>> The linux webrev contains unrelated UseLargePages changes! >>>> >>>> Sorry for the mess with UseLargePages changes :/ >>>> >>>> I've fixed the problems with the frequency (using a fixed number as >>>> before) and I kept the changes to minimum. >>>> >>>> I was hesitating about changing the elapsed_counter precision from >>>> microseconds to nanoseconds but since solaris and windows versions >>>> already use nanosecond ticks for elapsed_counter I think the change is >>>> safe. >>>> >>>> The update webrev: >>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>>> >>>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>>> >>>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>>> >>>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>>> >>>>>>>>>>>> This discussion also implies that the "elapsed time" we >>>>>>>>>>>> print in >>>>>>>>>>>> the >>>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>> >>>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>>> (class VMUptimeDCmd) which also relies on >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>> >>>>>>>>>>> Also the reported GC pauses duration might be wrong since it >>>>>>>>>>> uses >>>>>>>>>>> Management::timestamp(). >>>>>>>>>>> >>>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>>> honestly, >>>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>>> once >>>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>>> equivalent. >>>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>>> >>>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>>> current >>>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>>> few >>>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>>> before >>>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>>> >>>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>>> the >>>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>>> first 8 >>>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>>> right >>>>>>>>>> now. >>>>>>>>> >>>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>>> been >>>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>>> (yes a >>>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>>> modified >>>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>>> to be >>>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>>> attempted >>>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>>> based >>>>>>>>> timestamp with the TOD. :( >>>>>>>> >>>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>>> value. It >>>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>>> For Linux/BSD the TOD is used directly. >>>>>>>> >>>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>>> follow the same logic would be really that disruptive. >>>>>>> >>>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>>> interesting experiment. >>>>>> >>>>>> The change is rather simple and tests ok. All the means to get a >>>>>> monotonic timestamp are already there and proved to work. The core >>>>>> tests >>>>>> in JPRT went fine. >>>>>> >>>>>> The updated webrev is at >>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday >>>>>>>>>>>>>>>> so is >>>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>>> make me >>>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>>> because of >>>>>>>>>>>>>> the way these are used in logging etc. Certainly not >>>>>>>>>>>>>> something >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>>> that >>>>>>>>>>>>>> can then >>>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>>> >>>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>>> >>>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks >>>>>>>>>>>>> where >>>>>>>>>>>>> possible. >>>>>>>>>>>>> >>>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From karen.kinnear at oracle.com Thu Oct 17 11:17:54 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Oct 2013 14:17:54 -0400 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> Message-ID: <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> Added test (thanks to Robert Field). Please review: -------------- next part -------------- thanks, Karen On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: > Please review quickly: > > webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026365 > > Verifier called is_reference_assignable, which called resolve_or_null, which was looking for > the anonymous class in the system dictionary, where it is not. So this will allow more anonymous > class cases to get through the verifier while still doing validity checking (but on the host class only, > not on the anonymous class). > > Tested: > Robert's new test: reduct (which he will check in as part of the lambda side of this change) > Lam > Lam1 > > in progress: vm.quick, java.lang, java.util, Nashorn > > thanks, > Karen > > p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? > > p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he > had given me > From daniel.daugherty at oracle.com Thu Oct 17 12:41:47 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Oct 2013 13:41:47 -0600 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> Message-ID: <52603D7B.4050401@oracle.com> I'm guessing that you mean this webrev: > http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ src/share/vm/classfile/verifier.cpp This webrev is against the current T&L/hotspot version instead of the version that is being sync'ed down from JDK8. test/TEST.groups runtime/8026365/InvokeSpecialAnonTest.java is added to this list but is not included in the webrev. Why is runtime/6878713/Test6878713.sh deleted in this webrev? Dan On 10/17/13 12:17 PM, Karen Kinnear wrote: > Added test (thanks to Robert Field). Please review: > > > > > thanks, > Karen > > On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: > >> Please review quickly: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >> >> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >> class cases to get through the verifier while still doing validity checking (but on the host class only, >> not on the anonymous class). >> >> Tested: >> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >> Lam >> Lam1 >> >> in progress: vm.quick, java.lang, java.util, Nashorn >> >> thanks, >> Karen >> >> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >> >> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >> had given me >> From karen.kinnear at oracle.com Thu Oct 17 13:41:06 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Oct 2013 16:41:06 -0400 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <52603D7B.4050401@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> Message-ID: <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> No - I attached the file directly. I couldn't figure out how to get webrev to show a new file without doing a commit. So I didn't use the webrev for review - but thanks for looking at it - because I forgot to send the TEST.groups. If I understand correctly, we now need to add to that whenever adding a test that needs the full jdk as this one does for the asm library. That said - I had to change test/TEST.groups in order to run my test - because the test itself doesn't exist and the new mechanism to split things based on profiles seems intolerant - i.e. it doesn't just report a problem and continue - it stops dead in its tracks. I'm sure David H will be delighted to fix that. On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: > I'm guessing that you mean this webrev: > > > http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ > > src/share/vm/classfile/verifier.cpp > This webrev is against the current T&L/hotspot version instead > of the version that is being sync'ed down from JDK8. > > test/TEST.groups > runtime/8026365/InvokeSpecialAnonTest.java is added to this list > but is not included in the webrev. > > Why is runtime/6878713/Test6878713.sh deleted in this webrev? > > Dan > > > > > On 10/17/13 12:17 PM, Karen Kinnear wrote: >> Added test (thanks to Robert Field). Please review: >> >> >> >> >> thanks, >> Karen >> >> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >> >>> Please review quickly: >>> >>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>> >>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>> not on the anonymous class). >>> >>> Tested: >>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>> Lam >>> Lam1 >>> >>> in progress: vm.quick, java.lang, java.util, Nashorn >>> >>> thanks, >>> Karen >>> >>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>> >>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>> had given me >>> > From igor.veresov at oracle.com Thu Oct 17 13:51:07 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 17 Oct 2013 20:51:07 +0000 Subject: hg: hsx/hotspot-main/hotspot: 30 new changesets Message-ID: <20131017205225.35BFA624D8@hg.openjdk.java.net> Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5f1241525a01 Merge Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dd2cf1d1248b Merge Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed2c74787eb5 Merge Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1263c7e17e1c Merge Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh From erik.helin at oracle.com Thu Oct 17 14:28:52 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 17 Oct 2013 23:28:52 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <525ED138.1000305@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> Message-ID: <20131017212852.GA6066@ehelin-thinkpad> Hi Mikael and Coleen, thanks for your reviews! On 2013-10-16, Mikael Gerdin wrote: > jvmtiImpl.hpp: > Since clone() uses unhandled oops, and is only supposed to be used > by the VM operation, would it make sense to > assert(SafepointSynchronize::is_at_safepoint())? > > 196 GrowableElement *clone() { > 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); Agree, I've updated the patch. A new webrev is located at: http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ On 2013-10-16, Mikael Gerdin wrote: > jvmtiEnv.cpp: > Have you verified that the generated JVMTI entry point contains a > ResourceMark or is it just not needed? > - ResourceMark rm; > + HandleMark hm; The JVMTI entry point does not contain a ResourceMark. However, I have verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint nor for jvmtiEnv::ClearBreapoint. The only codes that needs a ResourceMark is JvmtiBreakpoints::prints, but that method already has a ResourceMark. On 2013-10-16, Coleen Phillimore wrote: > Did you run the nsk.jvmti.testlist tests too though? No, I had not run the nsk.jvmti.testlist test, but I have now :) I run both with and without the patch on the latest hsx/hotspot-gc. I also run with and without -XX:+CheckUnhandledOops. The results were all the same: 598 passed an 11 failed (the same tests for all combinations). So, the patch does not introduce any regressions for this test suite. Thanks, Erik On 2013-10-16, Mikael Gerdin wrote: > Erik, > > (it's not necessary to cross-post between hotspot-dev and > hotspot-gc-dev, so I removed hotspot-gc from the CC list) > > On 2013-10-16 18:09, Erik Helin wrote: > >Hi all, > > > >this patch fixes an issue where an oop in JvmtiBreakpoint, > >JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > > >Instead of registering the oop as an unhandled oop, which would have > >worked, I decided to wrap the oop in a handle as long as it is on the > >stack. > > > >A JvmtiBreakpoint is created on the stack by the two methods > >JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > >JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > >to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > >at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > >the values from the stack allocated JvmtiBreakpoint and then place/clear the > >newly alloacted JvmtiBreakpoint in > >JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > > >I have updated to the code to check that the public constructor is only > >used to allocate JvmtiBreakpoints on the stack (to warn a future > >programmer if he/she decides to allocate one on the heap). The > >class_loader oop is now wrapped in a Handle for stack allocated > >JvmtiBreakpoints. > > > >Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > >the oops_do method of VM_ChangeBreakpoints can be removed. This also > >makes the oop in the handle safe for use after the VM_ChangeBreakpoint > >operation is finished. > > > >The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > >visited by the GC via jvmtiExport::oops_do -> > >JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > >GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > >added to. > > > >I've also removed some dead code to simplify the change: > >- GrowableCache::insert > >- JvmtiBreakpoint::copy > >- JvmtiBreakpoint::lessThan > >- GrowableElement::lessThan > > > >Finally, I also formatted JvmtiEnv::ClearBreakpoint and > >Jvmti::SetBreakpoint exactly the same to highlight that they share all > >code except one line. Unfortunately, I was not able to remove this code > >duplication in a good way. > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > jvmtiImpl.hpp: > Since clone() uses unhandled oops, and is only supposed to be used > by the VM operation, would it make sense to > assert(SafepointSynchronize::is_at_safepoint())? > > 196 GrowableElement *clone() { > 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); > > jvmtiImpl.cpp: > No comments. > > jvmtiEnv.cpp: > Have you verified that the generated JVMTI entry point contains a > ResourceMark or is it just not needed? > - ResourceMark rm; > + HandleMark hm; > > Otherwise the code change looks good. > > > One thing that you didn't describe here, but which was related to > the bug (which we discussed) was the fact that the old code tried to > "do the right thing" WRT CheckUnhandledOops, but it incorrectly > added a Method*: > > thread->allow_unhandled_oop((oop*)&_method); > > We should take care to find other such places where we try to put a > non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in > the unhandled oops code. > > /Mikael > > > > >Testing: > >- JPRT > >- The four tests that were failing are now passing > > > >Thanks, > >Erik > > > From daniel.daugherty at oracle.com Thu Oct 17 14:30:23 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Oct 2013 15:30:23 -0600 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> Message-ID: <526056EF.70505@oracle.com> On 10/17/13 2:41 PM, Karen Kinnear wrote: > No - I attached the file directly. So the attach probably worked for everyone that was a direct recipient. However, for those (like me) that got the e-mail via hotspot-dev at openjdk.java.net, the attachment got stripped. > I couldn't figure out how to get webrev to show a new file without > doing a commit. An "hg add test/runtime/8026365/InvokeSpecialAnonTest.java" should do the trick or just pass a file list to webrev that includes test/runtime/8026365/InvokeSpecialAnonTest.java and I _think_ that'll do it also. Dan > So I didn't use the webrev for review - but thanks for looking at it - > because I > forgot to send the TEST.groups. If I understand correctly, we now need > to add to that whenever adding > a test that needs the full jdk as this one does for the asm library. > > That said - I had to change test/TEST.groups in order to run my test - > because the test itself > doesn't exist and the new mechanism to split things based on profiles > seems intolerant - i.e. it doesn't > just report a problem and continue - it stops dead in its tracks. I'm > sure David H will be delighted to fix that. > > > On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: > >> I'm guessing that you mean this webrev: >> >> > http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >> >> src/share/vm/classfile/verifier.cpp >> This webrev is against the current T&L/hotspot version instead >> of the version that is being sync'ed down from JDK8. >> >> test/TEST.groups >> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >> but is not included in the webrev. >> >> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >> >> Dan >> >> >> >> >> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>> Added test (thanks to Robert Field). Please review: >>> >>> >>> >>> thanks, >>> Karen >>> >>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>> >>>> Please review quickly: >>>> >>>> webrev:http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>> bug:https://bugs.openjdk.java.net/browse/JDK-8026365 >>>> >>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>> not on the anonymous class). >>>> >>>> Tested: >>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>> Lam >>>> Lam1 >>>> >>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>> >>>> thanks, >>>> Karen >>>> >>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>> >>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>> had given me >>>> >> > From karen.kinnear at oracle.com Thu Oct 17 14:41:32 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Oct 2013 17:41:32 -0400 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <526056EF.70505@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> <526056EF.70505@oracle.com> Message-ID: <3F5AE88F-4685-4EF0-88ED-194C0A9C793F@oracle.com> Test webrev: http://cr.openjdk.java.net/%7Eacorn/8026365.test/webrev/ Note I removed 6878713/Test6878713.sh from the TEST.groups file because the directory no longer exists and this prevents other tests from running. thanks, Karen On Oct 17, 2013, at 5:30 PM, Daniel D. Daugherty wrote: > On 10/17/13 2:41 PM, Karen Kinnear wrote: >> No - I attached the file directly. > > So the attach probably worked for everyone that was a direct > recipient. However, for those (like me) that got the e-mail > via hotspot-dev at openjdk.java.net, the attachment got stripped. > > >> I couldn't figure out how to get webrev to show a new file without >> doing a commit. > > An "hg add test/runtime/8026365/InvokeSpecialAnonTest.java" > should do the trick or just pass a file list to webrev > that includes test/runtime/8026365/InvokeSpecialAnonTest.java > and I _think_ that'll do it also. > > Dan > > > >> So I didn't use the webrev for review - but thanks for looking at it - because I >> forgot to send the TEST.groups. If I understand correctly, we now need to add to that whenever adding >> a test that needs the full jdk as this one does for the asm library. >> >> That said - I had to change test/TEST.groups in order to run my test - because the test itself >> doesn't exist and the new mechanism to split things based on profiles seems intolerant - i.e. it doesn't >> just report a problem and continue - it stops dead in its tracks. I'm sure David H will be delighted to fix that. >> >> >> On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: >> >>> I'm guessing that you mean this webrev: >>> >>> > http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >>> >>> src/share/vm/classfile/verifier.cpp >>> This webrev is against the current T&L/hotspot version instead >>> of the version that is being sync'ed down from JDK8. >>> >>> test/TEST.groups >>> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >>> but is not included in the webrev. >>> >>> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >>> >>> Dan >>> >>> >>> >>> >>> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>>> Added test (thanks to Robert Field). Please review: >>>> >>>> >>>> >>>> thanks, >>>> Karen >>>> >>>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>>> >>>>> Please review quickly: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>>> >>>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>>> not on the anonymous class). >>>>> >>>>> Tested: >>>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>>> Lam >>>>> Lam1 >>>>> >>>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>>> >>>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>>> had given me >>>>> >>> >> > From daniel.daugherty at oracle.com Thu Oct 17 14:58:09 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Oct 2013 15:58:09 -0600 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <3F5AE88F-4685-4EF0-88ED-194C0A9C793F@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> <526056EF.70505@oracle.com> <3F5AE88F-4685-4EF0-88ED-194C0A9C793F@oracle.com> Message-ID: <52605D71.4050807@oracle.com> On 10/17/13 3:41 PM, Karen Kinnear wrote: > Test webrev: http://cr.openjdk.java.net/%7Eacorn/8026365.test/webrev/ test/TEST.groups No comments. test/runtime/8026365/InvokeSpecialAnonTest.java line 32: * @run main/othervm -Xbootclasspath/a:. -Xverify:all InvokeSpecialAnonTest I thought the '-Xbootclasspath/a:.' part wasn't working? Or did this: '-XDignore.symbol.file' make things happy again? Thumbs up. The removal of 6878713/Test6878713.sh was done via: changeset: 5391:d574419c5372 user: mseledtsov date: Wed Oct 02 15:17:20 2013 +0200 summary: 8025671: Test name changed, test list not updated. Test6878713.sh which is in JDK8-B112/HSX-25-B54 so you'll pickup that change when you merge with Lana's sync-down from JDK8. Dan > > Note I removed 6878713/Test6878713.sh from the TEST.groups file > because the directory no longer exists and this prevents other tests > from running. > > thanks, > Karen > > On Oct 17, 2013, at 5:30 PM, Daniel D. Daugherty wrote: > >> On 10/17/13 2:41 PM, Karen Kinnear wrote: >>> No - I attached the file directly. >> >> So the attach probably worked for everyone that was a direct >> recipient. However, for those (like me) that got the e-mail >> via hotspot-dev at openjdk.java.net, the attachment got stripped. >> >> >>> I couldn't figure out how to get webrev to show a new file without >>> doing a commit. >> >> An "hg add test/runtime/8026365/InvokeSpecialAnonTest.java" >> should do the trick or just pass a file list to webrev >> that includes test/runtime/8026365/InvokeSpecialAnonTest.java >> and I _think_ that'll do it also. >> >> Dan >> >> >> >>> So I didn't use the webrev for review - but thanks for looking at it >>> - because I >>> forgot to send the TEST.groups. If I understand correctly, we now >>> need to add to that whenever adding >>> a test that needs the full jdk as this one does for the asm library. >>> >>> That said - I had to change test/TEST.groups in order to run my test >>> - because the test itself >>> doesn't exist and the new mechanism to split things based on >>> profiles seems intolerant - i.e. it doesn't >>> just report a problem and continue - it stops dead in its tracks. >>> I'm sure David H will be delighted to fix that. >>> >>> >>> On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: >>> >>>> I'm guessing that you mean this webrev: >>>> >>>> > http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >>>> >>>> src/share/vm/classfile/verifier.cpp >>>> This webrev is against the current T&L/hotspot version instead >>>> of the version that is being sync'ed down from JDK8. >>>> >>>> test/TEST.groups >>>> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >>>> but is not included in the webrev. >>>> >>>> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>>>> Added test (thanks to Robert Field). Please review: >>>>> >>>>> >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>>>> >>>>>> Please review quickly: >>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8026365 >>>>>> >>>>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>>>> not on the anonymous class). >>>>>> >>>>>> Tested: >>>>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>>>> Lam >>>>>> Lam1 >>>>>> >>>>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>>>> >>>>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>>>> had given me >>>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Oct 17 20:06:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2013 13:06:51 +1000 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> Message-ID: <5260A5CB.2070504@oracle.com> On 18/10/2013 6:41 AM, Karen Kinnear wrote: > No - I attached the file directly. I couldn't figure out how to get webrev to show a new file without > doing a commit. So I didn't use the webrev for review - but thanks for looking at it - because I > forgot to send the TEST.groups. If I understand correctly, we now need to add to that whenever adding > a test that needs the full jdk as this one does for the asm library. > > That said - I had to change test/TEST.groups in order to run my test - because the test itself > doesn't exist and the new mechanism to split things based on profiles seems intolerant - i.e. it doesn't > just report a problem and continue - it stops dead in its tracks. I'm sure David H will be delighted to fix that. Not sure what you mean. If a group lists a test that doesn't exist then jtreg will report that while parsing the groups file but otherwise it is ignored. BTW I don't see why InvokeSpecialAnonTest.java is listed as needs_jdk ?? David ----- > > On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: > >> I'm guessing that you mean this webrev: >> >>> http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >> >> src/share/vm/classfile/verifier.cpp >> This webrev is against the current T&L/hotspot version instead >> of the version that is being sync'ed down from JDK8. >> >> test/TEST.groups >> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >> but is not included in the webrev. >> >> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >> >> Dan >> >> >> >> >> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>> Added test (thanks to Robert Field). Please review: >>> >>> >>> >>> >>> thanks, >>> Karen >>> >>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>> >>>> Please review quickly: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>> >>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>> not on the anonymous class). >>>> >>>> Tested: >>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>> Lam >>>> Lam1 >>>> >>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>> >>>> thanks, >>>> Karen >>>> >>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>> >>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>> had given me >>>> >> > From karen.kinnear at oracle.com Thu Oct 17 20:16:10 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Oct 2013 23:16:10 -0400 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <5260A5CB.2070504@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> <5260A5CB.2070504@oracle.com> Message-ID: <7B37E46C-1968-43ED-A6F0-DC0E1F9B645F@oracle.com> David, InvokeSpecialAnonTest.java needs the jdk to provide objectweb.asm to build, in fact it needed a special flag to find it. But let me know if that is in one of the smaller profiles - I don't know where to look that up. I will retry the missing test directory and get back to you on that. Sounds like I was mistaken (?) thanks, Karen On Oct 17, 2013, at 11:06 PM, David Holmes wrote: > On 18/10/2013 6:41 AM, Karen Kinnear wrote: >> No - I attached the file directly. I couldn't figure out how to get webrev to show a new file without >> doing a commit. So I didn't use the webrev for review - but thanks for looking at it - because I >> forgot to send the TEST.groups. If I understand correctly, we now need to add to that whenever adding >> a test that needs the full jdk as this one does for the asm library. >> >> That said - I had to change test/TEST.groups in order to run my test - because the test itself >> doesn't exist and the new mechanism to split things based on profiles seems intolerant - i.e. it doesn't >> just report a problem and continue - it stops dead in its tracks. I'm sure David H will be delighted to fix that. > > Not sure what you mean. If a group lists a test that doesn't exist then jtreg will report that while parsing the groups file but otherwise it is ignored. > > BTW I don't see why InvokeSpecialAnonTest.java is listed as needs_jdk ?? > > David > ----- > >> >> On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: >> >>> I'm guessing that you mean this webrev: >>> >>>> http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >>> >>> src/share/vm/classfile/verifier.cpp >>> This webrev is against the current T&L/hotspot version instead >>> of the version that is being sync'ed down from JDK8. >>> >>> test/TEST.groups >>> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >>> but is not included in the webrev. >>> >>> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >>> >>> Dan >>> >>> >>> >>> >>> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>>> Added test (thanks to Robert Field). Please review: >>>> >>>> >>>> >>>> >>>> thanks, >>>> Karen >>>> >>>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>>> >>>>> Please review quickly: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>>> >>>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>>> not on the anonymous class). >>>>> >>>>> Tested: >>>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>>> Lam >>>>> Lam1 >>>>> >>>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>>> >>>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>>> had given me >>>>> >>> >> From david.holmes at oracle.com Thu Oct 17 21:27:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2013 14:27:44 +1000 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <7B37E46C-1968-43ED-A6F0-DC0E1F9B645F@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> <5260A5CB.2070504@oracle.com> <7B37E46C-1968-43ED-A6F0-DC0E1F9B645F@oracle.com> Message-ID: <5260B8C0.2030401@oracle.com> On 18/10/2013 1:16 PM, Karen Kinnear wrote: > David, > > InvokeSpecialAnonTest.java needs the jdk to provide objectweb.asm to build, in fact it needed a special flag to > find it. But let me know if that is in one of the smaller profiles - I don't know where to look that up. As discussed on IM all of the jdk.* packages are available in compact1 so there seems no reason to restrict this test to running on a JDK. This can be corrected later. > I will retry the missing test directory and get back to you on that. Sounds like I was mistaken (?) It is the first I've heard of such a problem and I couldn't reproduce it with a simple group containing one real and one non-existent test. Thanks, David > thanks, > Karen > > On Oct 17, 2013, at 11:06 PM, David Holmes wrote: > >> On 18/10/2013 6:41 AM, Karen Kinnear wrote: >>> No - I attached the file directly. I couldn't figure out how to get webrev to show a new file without >>> doing a commit. So I didn't use the webrev for review - but thanks for looking at it - because I >>> forgot to send the TEST.groups. If I understand correctly, we now need to add to that whenever adding >>> a test that needs the full jdk as this one does for the asm library. >>> >>> That said - I had to change test/TEST.groups in order to run my test - because the test itself >>> doesn't exist and the new mechanism to split things based on profiles seems intolerant - i.e. it doesn't >>> just report a problem and continue - it stops dead in its tracks. I'm sure David H will be delighted to fix that. >> >> Not sure what you mean. If a group lists a test that doesn't exist then jtreg will report that while parsing the groups file but otherwise it is ignored. >> >> BTW I don't see why InvokeSpecialAnonTest.java is listed as needs_jdk ?? >> >> David >> ----- >> >>> >>> On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: >>> >>>> I'm guessing that you mean this webrev: >>>> >>>>> http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >>>> >>>> src/share/vm/classfile/verifier.cpp >>>> This webrev is against the current T&L/hotspot version instead >>>> of the version that is being sync'ed down from JDK8. >>>> >>>> test/TEST.groups >>>> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >>>> but is not included in the webrev. >>>> >>>> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>>>> Added test (thanks to Robert Field). Please review: >>>>> >>>>> >>>>> >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>>>> >>>>>> Please review quickly: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>>>> >>>>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>>>> not on the anonymous class). >>>>>> >>>>>> Tested: >>>>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>>>> Lam >>>>>> Lam1 >>>>>> >>>>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>>>> >>>>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>>>> had given me >>>>>> >>>> >>> > From serguei.spitsyn at oracle.com Thu Oct 17 22:49:31 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Oct 2013 22:49:31 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131017212852.GA6066@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> Message-ID: <5260CBEB.1000902@oracle.com> Hi Erik, The fix looks good in general. But one thing is confusing in the fix. Why do you keep both _class_loader and _class_loader_handle in the JvmtiBreakpoint class? Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test suites as well. Thanks, Serguei On 10/17/13 2:28 PM, Erik Helin wrote: > Hi Mikael and Coleen, > > thanks for your reviews! > > On 2013-10-16, Mikael Gerdin wrote: >> jvmtiImpl.hpp: >> Since clone() uses unhandled oops, and is only supposed to be used >> by the VM operation, would it make sense to >> assert(SafepointSynchronize::is_at_safepoint())? >> >> 196 GrowableElement *clone() { >> 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); > Agree, I've updated the patch. A new webrev is located at: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ > > On 2013-10-16, Mikael Gerdin wrote: >> jvmtiEnv.cpp: >> Have you verified that the generated JVMTI entry point contains a >> ResourceMark or is it just not needed? >> - ResourceMark rm; >> + HandleMark hm; > The JVMTI entry point does not contain a ResourceMark. However, I have > verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint > nor for jvmtiEnv::ClearBreapoint. The only codes that needs a > ResourceMark is JvmtiBreakpoints::prints, but that method already has a > ResourceMark. > > On 2013-10-16, Coleen Phillimore wrote: >> Did you run the nsk.jvmti.testlist tests too though? > No, I had not run the nsk.jvmti.testlist test, but I have now :) > > I run both with and without the patch on the latest hsx/hotspot-gc. I > also run with and without -XX:+CheckUnhandledOops. The results were all > the same: 598 passed an 11 failed (the same tests for all combinations). > So, the patch does not introduce any regressions for this test suite. > > Thanks, > Erik > > On 2013-10-16, Mikael Gerdin wrote: >> Erik, >> >> (it's not necessary to cross-post between hotspot-dev and >> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >> >> On 2013-10-16 18:09, Erik Helin wrote: >>> Hi all, >>> >>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. >>> >>> Instead of registering the oop as an unhandled oop, which would have >>> worked, I decided to wrap the oop in a handle as long as it is on the >>> stack. >>> >>> A JvmtiBreakpoint is created on the stack by the two methods >>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>> JvmtiBreakpoint is only created to carry the Method*, jlocation and oop >>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when >>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy >>> the values from the stack allocated JvmtiBreakpoint and then place/clear the >>> newly alloacted JvmtiBreakpoint in >>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>> >>> I have updated to the code to check that the public constructor is only >>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>> programmer if he/she decides to allocate one on the heap). The >>> class_loader oop is now wrapped in a Handle for stack allocated >>> JvmtiBreakpoints. >>> >>> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >>> operation is finished. >>> >>> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >>> visited by the GC via jvmtiExport::oops_do -> >>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>> added to. >>> >>> I've also removed some dead code to simplify the change: >>> - GrowableCache::insert >>> - JvmtiBreakpoint::copy >>> - JvmtiBreakpoint::lessThan >>> - GrowableElement::lessThan >>> >>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>> Jvmti::SetBreakpoint exactly the same to highlight that they share all >>> code except one line. Unfortunately, I was not able to remove this code >>> duplication in a good way. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >> jvmtiImpl.hpp: >> Since clone() uses unhandled oops, and is only supposed to be used >> by the VM operation, would it make sense to >> assert(SafepointSynchronize::is_at_safepoint())? >> >> 196 GrowableElement *clone() { >> 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); >> >> jvmtiImpl.cpp: >> No comments. >> >> jvmtiEnv.cpp: >> Have you verified that the generated JVMTI entry point contains a >> ResourceMark or is it just not needed? >> - ResourceMark rm; >> + HandleMark hm; >> >> Otherwise the code change looks good. >> >> >> One thing that you didn't describe here, but which was related to >> the bug (which we discussed) was the fact that the old code tried to >> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >> added a Method*: >> >> thread->allow_unhandled_oop((oop*)&_method); >> >> We should take care to find other such places where we try to put a >> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >> the unhandled oops code. >> >> /Mikael >> >>> Testing: >>> - JPRT >>> - The four tests that were failing are now passing >>> >>> Thanks, >>> Erik >>> From serguei.spitsyn at oracle.com Thu Oct 17 22:51:14 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Oct 2013 22:51:14 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260CBEB.1000902@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> Message-ID: <5260CC52.7050306@oracle.com> I forgot to say "thank you" for taking care about this issue! Thanks, Serguei On 10/17/13 10:49 PM, serguei.spitsyn at oracle.com wrote: > Hi Erik, > > The fix looks good in general. > > But one thing is confusing in the fix. > Why do you keep both _class_loader and _class_loader_handle in the > JvmtiBreakpoint class? > > Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > suites as well. > > Thanks, > Serguei > > > On 10/17/13 2:28 PM, Erik Helin wrote: >> Hi Mikael and Coleen, >> >> thanks for your reviews! >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >> Agree, I've updated the patch. A new webrev is located at: >> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >> The JVMTI entry point does not contain a ResourceMark. However, I have >> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >> ResourceMark is JvmtiBreakpoints::prints, but that method already has a >> ResourceMark. >> >> On 2013-10-16, Coleen Phillimore wrote: >>> Did you run the nsk.jvmti.testlist tests too though? >> No, I had not run the nsk.jvmti.testlist test, but I have now :) >> >> I run both with and without the patch on the latest hsx/hotspot-gc. I >> also run with and without -XX:+CheckUnhandledOops. The results were all >> the same: 598 passed an 11 failed (the same tests for all combinations). >> So, the patch does not introduce any regressions for this test suite. >> >> Thanks, >> Erik >> >> On 2013-10-16, Mikael Gerdin wrote: >>> Erik, >>> >>> (it's not necessary to cross-post between hotspot-dev and >>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>> >>> On 2013-10-16 18:09, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>> detector. >>>> >>>> Instead of registering the oop as an unhandled oop, which would have >>>> worked, I decided to wrap the oop in a handle as long as it is on the >>>> stack. >>>> >>>> A JvmtiBreakpoint is created on the stack by the two methods >>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>> JvmtiBreakpoint is only created to carry the Method*, jlocation and >>>> oop >>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>> when >>>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, >>>> copy >>>> the values from the stack allocated JvmtiBreakpoint and then >>>> place/clear the >>>> newly alloacted JvmtiBreakpoint in >>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>> >>>> I have updated to the code to check that the public constructor is >>>> only >>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>> programmer if he/she decides to allocate one on the heap). The >>>> class_loader oop is now wrapped in a Handle for stack allocated >>>> JvmtiBreakpoints. >>>> >>>> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >>>> operation is finished. >>>> >>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >>>> visited by the GC via jvmtiExport::oops_do -> >>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>>> added to. >>>> >>>> I've also removed some dead code to simplify the change: >>>> - GrowableCache::insert >>>> - JvmtiBreakpoint::copy >>>> - JvmtiBreakpoint::lessThan >>>> - GrowableElement::lessThan >>>> >>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>> Jvmti::SetBreakpoint exactly the same to highlight that they share all >>>> code except one line. Unfortunately, I was not able to remove this >>>> code >>>> duplication in a good way. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >>> >>> jvmtiImpl.cpp: >>> No comments. >>> >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >>> >>> Otherwise the code change looks good. >>> >>> >>> One thing that you didn't describe here, but which was related to >>> the bug (which we discussed) was the fact that the old code tried to >>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>> added a Method*: >>> >>> thread->allow_unhandled_oop((oop*)&_method); >>> >>> We should take care to find other such places where we try to put a >>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>> the unhandled oops code. >>> >>> /Mikael >>> >>>> Testing: >>>> - JPRT >>>> - The four tests that were failing are now passing >>>> >>>> Thanks, >>>> Erik >>>> > From david.holmes at oracle.com Thu Oct 17 23:03:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2013 16:03:20 +1000 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260CBEB.1000902@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> Message-ID: <5260CF28.2040403@oracle.com> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: > Hi Erik, > > The fix looks good in general. > > But one thing is confusing in the fix. > Why do you keep both _class_loader and _class_loader_handle in the > JvmtiBreakpoint class? Even more confusing to me is the fact the neither of these seem to actually be used anywhere ??? But if we have the Handle then the oop is redundant AFAICS. David > Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > suites as well. > > Thanks, > Serguei > > > On 10/17/13 2:28 PM, Erik Helin wrote: >> Hi Mikael and Coleen, >> >> thanks for your reviews! >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >> Agree, I've updated the patch. A new webrev is located at: >> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >> The JVMTI entry point does not contain a ResourceMark. However, I have >> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >> ResourceMark is JvmtiBreakpoints::prints, but that method already has a >> ResourceMark. >> >> On 2013-10-16, Coleen Phillimore wrote: >>> Did you run the nsk.jvmti.testlist tests too though? >> No, I had not run the nsk.jvmti.testlist test, but I have now :) >> >> I run both with and without the patch on the latest hsx/hotspot-gc. I >> also run with and without -XX:+CheckUnhandledOops. The results were all >> the same: 598 passed an 11 failed (the same tests for all combinations). >> So, the patch does not introduce any regressions for this test suite. >> >> Thanks, >> Erik >> >> On 2013-10-16, Mikael Gerdin wrote: >>> Erik, >>> >>> (it's not necessary to cross-post between hotspot-dev and >>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>> >>> On 2013-10-16 18:09, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>> detector. >>>> >>>> Instead of registering the oop as an unhandled oop, which would have >>>> worked, I decided to wrap the oop in a handle as long as it is on the >>>> stack. >>>> >>>> A JvmtiBreakpoint is created on the stack by the two methods >>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>> JvmtiBreakpoint is only created to carry the Method*, jlocation and oop >>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>> when >>>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy >>>> the values from the stack allocated JvmtiBreakpoint and then >>>> place/clear the >>>> newly alloacted JvmtiBreakpoint in >>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>> >>>> I have updated to the code to check that the public constructor is only >>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>> programmer if he/she decides to allocate one on the heap). The >>>> class_loader oop is now wrapped in a Handle for stack allocated >>>> JvmtiBreakpoints. >>>> >>>> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >>>> operation is finished. >>>> >>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >>>> visited by the GC via jvmtiExport::oops_do -> >>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>>> added to. >>>> >>>> I've also removed some dead code to simplify the change: >>>> - GrowableCache::insert >>>> - JvmtiBreakpoint::copy >>>> - JvmtiBreakpoint::lessThan >>>> - GrowableElement::lessThan >>>> >>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>> Jvmti::SetBreakpoint exactly the same to highlight that they share all >>>> code except one line. Unfortunately, I was not able to remove this code >>>> duplication in a good way. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >>> >>> jvmtiImpl.cpp: >>> No comments. >>> >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >>> >>> Otherwise the code change looks good. >>> >>> >>> One thing that you didn't describe here, but which was related to >>> the bug (which we discussed) was the fact that the old code tried to >>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>> added a Method*: >>> >>> thread->allow_unhandled_oop((oop*)&_method); >>> >>> We should take care to find other such places where we try to put a >>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>> the unhandled oops code. >>> >>> /Mikael >>> >>>> Testing: >>>> - JPRT >>>> - The four tests that were failing are now passing >>>> >>>> Thanks, >>>> Erik >>>> > From karen.kinnear at oracle.com Fri Oct 18 00:05:54 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Fri, 18 Oct 2013 07:05:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8026365: NoClassDefinitionFound for anonymous class invokespecial. Message-ID: <20131018070604.594D4624FE@hg.openjdk.java.net> Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups From serguei.spitsyn at oracle.com Fri Oct 18 00:24:30 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 00:24:30 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260CF28.2040403@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> Message-ID: <5260E22E.1010503@oracle.com> On 10/17/13 11:03 PM, David Holmes wrote: > On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >> Hi Erik, >> >> The fix looks good in general. >> >> But one thing is confusing in the fix. >> Why do you keep both _class_loader and _class_loader_handle in the >> JvmtiBreakpoint class? > > Even more confusing to me is the fact the neither of these seem to > actually be used anywhere ??? Nice catch, David. I do not see too any of them is really used. Is it a leftover after the permgen elimination? > > But if we have the Handle then the oop is redundant AFAICS. Right. The issue is that the oop version is used in the oops_do. Not sure if we can get rid of oops_do. It may have an empty body though. Thanks, Serguei > > David > >> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >> suites as well. >> >> Thanks, >> Serguei >> >> >> On 10/17/13 2:28 PM, Erik Helin wrote: >>> Hi Mikael and Coleen, >>> >>> thanks for your reviews! >>> >>> On 2013-10-16, Mikael Gerdin wrote: >>>> jvmtiImpl.hpp: >>>> Since clone() uses unhandled oops, and is only supposed to be used >>>> by the VM operation, would it make sense to >>>> assert(SafepointSynchronize::is_at_safepoint())? >>>> >>>> 196 GrowableElement *clone() { >>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>> _class_loader_handle); >>> Agree, I've updated the patch. A new webrev is located at: >>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>> >>> On 2013-10-16, Mikael Gerdin wrote: >>>> jvmtiEnv.cpp: >>>> Have you verified that the generated JVMTI entry point contains a >>>> ResourceMark or is it just not needed? >>>> - ResourceMark rm; >>>> + HandleMark hm; >>> The JVMTI entry point does not contain a ResourceMark. However, I have >>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>> ResourceMark is JvmtiBreakpoints::prints, but that method already has a >>> ResourceMark. >>> >>> On 2013-10-16, Coleen Phillimore wrote: >>>> Did you run the nsk.jvmti.testlist tests too though? >>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>> >>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>> also run with and without -XX:+CheckUnhandledOops. The results were all >>> the same: 598 passed an 11 failed (the same tests for all >>> combinations). >>> So, the patch does not introduce any regressions for this test suite. >>> >>> Thanks, >>> Erik >>> >>> On 2013-10-16, Mikael Gerdin wrote: >>>> Erik, >>>> >>>> (it's not necessary to cross-post between hotspot-dev and >>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>> >>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>> detector. >>>>> >>>>> Instead of registering the oop as an unhandled oop, which would have >>>>> worked, I decided to wrap the oop in a handle as long as it is on the >>>>> stack. >>>>> >>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>> and oop >>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>> when >>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, >>>>> copy >>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>> place/clear the >>>>> newly alloacted JvmtiBreakpoint in >>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>> >>>>> I have updated to the code to check that the public constructor is >>>>> only >>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>> programmer if he/she decides to allocate one on the heap). The >>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>> JvmtiBreakpoints. >>>>> >>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>> handle, >>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>> makes the oop in the handle safe for use after the >>>>> VM_ChangeBreakpoint >>>>> operation is finished. >>>>> >>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>> will be >>>>> visited by the GC via jvmtiExport::oops_do -> >>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>>>> added to. >>>>> >>>>> I've also removed some dead code to simplify the change: >>>>> - GrowableCache::insert >>>>> - JvmtiBreakpoint::copy >>>>> - JvmtiBreakpoint::lessThan >>>>> - GrowableElement::lessThan >>>>> >>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>> Jvmti::SetBreakpoint exactly the same to highlight that they share >>>>> all >>>>> code except one line. Unfortunately, I was not able to remove this >>>>> code >>>>> duplication in a good way. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>> jvmtiImpl.hpp: >>>> Since clone() uses unhandled oops, and is only supposed to be used >>>> by the VM operation, would it make sense to >>>> assert(SafepointSynchronize::is_at_safepoint())? >>>> >>>> 196 GrowableElement *clone() { >>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>> _class_loader_handle); >>>> >>>> jvmtiImpl.cpp: >>>> No comments. >>>> >>>> jvmtiEnv.cpp: >>>> Have you verified that the generated JVMTI entry point contains a >>>> ResourceMark or is it just not needed? >>>> - ResourceMark rm; >>>> + HandleMark hm; >>>> >>>> Otherwise the code change looks good. >>>> >>>> >>>> One thing that you didn't describe here, but which was related to >>>> the bug (which we discussed) was the fact that the old code tried to >>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>> added a Method*: >>>> >>>> thread->allow_unhandled_oop((oop*)&_method); >>>> >>>> We should take care to find other such places where we try to put a >>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>> the unhandled oops code. >>>> >>>> /Mikael >>>> >>>>> Testing: >>>>> - JPRT >>>>> - The four tests that were failing are now passing >>>>> >>>>> Thanks, >>>>> Erik >>>>> >> From serguei.spitsyn at oracle.com Fri Oct 18 00:58:56 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 00:58:56 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260E22E.1010503@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> Message-ID: <5260EA40.50200@oracle.com> On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: > On 10/17/13 11:03 PM, David Holmes wrote: >> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Erik, >>> >>> The fix looks good in general. >>> >>> But one thing is confusing in the fix. >>> Why do you keep both _class_loader and _class_loader_handle in the >>> JvmtiBreakpoint class? >> >> Even more confusing to me is the fact the neither of these seem to >> actually be used anywhere ??? > > Nice catch, David. > I do not see too any of them is really used. > Is it a leftover after the permgen elimination? Maybe this is a rush judging. It depends on the closure->do_oop() that is used for traversing I thought that the KeepAliveClosure is used below (basing on the comment). class JvmtiBreakpoint : public GrowableElement { . . . void oops_do(OopClosure* f) { // Mark the method loader as live f->do_oop(&_class_loader); } This oops_do() is not needed if we have handle instead of oop. > >> >> But if we have the Handle then the oop is redundant AFAICS. > > Right. > The issue is that the oop version is used in the oops_do. > Not sure if we can get rid of oops_do. > It may have an empty body though. Getting rid of the oops_do will require more cleanup that needs to be accurate. Thanks, Serguei > > > Thanks, > Serguei > >> >> David >> >>> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >>> suites as well. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/17/13 2:28 PM, Erik Helin wrote: >>>> Hi Mikael and Coleen, >>>> >>>> thanks for your reviews! >>>> >>>> On 2013-10-16, Mikael Gerdin wrote: >>>>> jvmtiImpl.hpp: >>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>> by the VM operation, would it make sense to >>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>> >>>>> 196 GrowableElement *clone() { >>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>> _class_loader_handle); >>>> Agree, I've updated the patch. A new webrev is located at: >>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>>> >>>> On 2013-10-16, Mikael Gerdin wrote: >>>>> jvmtiEnv.cpp: >>>>> Have you verified that the generated JVMTI entry point contains a >>>>> ResourceMark or is it just not needed? >>>>> - ResourceMark rm; >>>>> + HandleMark hm; >>>> The JVMTI entry point does not contain a ResourceMark. However, I have >>>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>>> ResourceMark is JvmtiBreakpoints::prints, but that method already >>>> has a >>>> ResourceMark. >>>> >>>> On 2013-10-16, Coleen Phillimore wrote: >>>>> Did you run the nsk.jvmti.testlist tests too though? >>>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>>> >>>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>>> also run with and without -XX:+CheckUnhandledOops. The results were >>>> all >>>> the same: 598 passed an 11 failed (the same tests for all >>>> combinations). >>>> So, the patch does not introduce any regressions for this test suite. >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 2013-10-16, Mikael Gerdin wrote: >>>>> Erik, >>>>> >>>>> (it's not necessary to cross-post between hotspot-dev and >>>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>>> >>>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>>> detector. >>>>>> >>>>>> Instead of registering the oop as an unhandled oop, which would have >>>>>> worked, I decided to wrap the oop in a handle as long as it is on >>>>>> the >>>>>> stack. >>>>>> >>>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>>> and oop >>>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>>> when >>>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native >>>>>> heap, copy >>>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>>> place/clear the >>>>>> newly alloacted JvmtiBreakpoint in >>>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>>> >>>>>> I have updated to the code to check that the public constructor >>>>>> is only >>>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>>> programmer if he/she decides to allocate one on the heap). The >>>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>>> JvmtiBreakpoints. >>>>>> >>>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>>> handle, >>>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>>> makes the oop in the handle safe for use after the >>>>>> VM_ChangeBreakpoint >>>>>> operation is finished. >>>>>> >>>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>>> will be >>>>>> visited by the GC via jvmtiExport::oops_do -> >>>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is >>>>>> being >>>>>> added to. >>>>>> >>>>>> I've also removed some dead code to simplify the change: >>>>>> - GrowableCache::insert >>>>>> - JvmtiBreakpoint::copy >>>>>> - JvmtiBreakpoint::lessThan >>>>>> - GrowableElement::lessThan >>>>>> >>>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>>> Jvmti::SetBreakpoint exactly the same to highlight that they >>>>>> share all >>>>>> code except one line. Unfortunately, I was not able to remove >>>>>> this code >>>>>> duplication in a good way. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>>> jvmtiImpl.hpp: >>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>> by the VM operation, would it make sense to >>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>> >>>>> 196 GrowableElement *clone() { >>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>> _class_loader_handle); >>>>> >>>>> jvmtiImpl.cpp: >>>>> No comments. >>>>> >>>>> jvmtiEnv.cpp: >>>>> Have you verified that the generated JVMTI entry point contains a >>>>> ResourceMark or is it just not needed? >>>>> - ResourceMark rm; >>>>> + HandleMark hm; >>>>> >>>>> Otherwise the code change looks good. >>>>> >>>>> >>>>> One thing that you didn't describe here, but which was related to >>>>> the bug (which we discussed) was the fact that the old code tried to >>>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>>> added a Method*: >>>>> >>>>> thread->allow_unhandled_oop((oop*)&_method); >>>>> >>>>> We should take care to find other such places where we try to put a >>>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>>> the unhandled oops code. >>>>> >>>>> /Mikael >>>>> >>>>>> Testing: >>>>>> - JPRT >>>>>> - The four tests that were failing are now passing >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>> > From david.holmes at oracle.com Fri Oct 18 01:04:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2013 18:04:09 +1000 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260EA40.50200@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> Message-ID: <5260EB79.8080401@oracle.com> On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: > On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: >> On 10/17/13 11:03 PM, David Holmes wrote: >>> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Erik, >>>> >>>> The fix looks good in general. >>>> >>>> But one thing is confusing in the fix. >>>> Why do you keep both _class_loader and _class_loader_handle in the >>>> JvmtiBreakpoint class? >>> >>> Even more confusing to me is the fact the neither of these seem to >>> actually be used anywhere ??? >> >> Nice catch, David. >> I do not see too any of them is really used. >> Is it a leftover after the permgen elimination? > > Maybe this is a rush judging. > It depends on the closure->do_oop() that is used for traversing > I thought that the KeepAliveClosure is used below (basing on the comment). > > class JvmtiBreakpoint : public GrowableElement { > . . . > void oops_do(OopClosure* f) { > // Mark the method loader as live > f->do_oop(&_class_loader); > } > > This oops_do() is not needed if we have handle instead of oop. Ah! Maybe the only purpose of keeping the class_loader (whether oop or Handle) is that it is kept alive outside of its normal lifecycle. But still we should only need the Handle or the Oop, not both. And if there is no oop we should not need an oops_do. David > >> >>> >>> But if we have the Handle then the oop is redundant AFAICS. >> >> Right. >> The issue is that the oop version is used in the oops_do. >> Not sure if we can get rid of oops_do. >> It may have an empty body though. > > Getting rid of the oops_do will require more cleanup that needs to be > accurate. > > > Thanks, > Serguei > >> >> >> Thanks, >> Serguei >> >>> >>> David >>> >>>> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >>>> suites as well. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/17/13 2:28 PM, Erik Helin wrote: >>>>> Hi Mikael and Coleen, >>>>> >>>>> thanks for your reviews! >>>>> >>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>> jvmtiImpl.hpp: >>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>> by the VM operation, would it make sense to >>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>> >>>>>> 196 GrowableElement *clone() { >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>> _class_loader_handle); >>>>> Agree, I've updated the patch. A new webrev is located at: >>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>>>> >>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>> jvmtiEnv.cpp: >>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>> ResourceMark or is it just not needed? >>>>>> - ResourceMark rm; >>>>>> + HandleMark hm; >>>>> The JVMTI entry point does not contain a ResourceMark. However, I have >>>>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>>>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>>>> ResourceMark is JvmtiBreakpoints::prints, but that method already >>>>> has a >>>>> ResourceMark. >>>>> >>>>> On 2013-10-16, Coleen Phillimore wrote: >>>>>> Did you run the nsk.jvmti.testlist tests too though? >>>>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>>>> >>>>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>>>> also run with and without -XX:+CheckUnhandledOops. The results were >>>>> all >>>>> the same: 598 passed an 11 failed (the same tests for all >>>>> combinations). >>>>> So, the patch does not introduce any regressions for this test suite. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>> Erik, >>>>>> >>>>>> (it's not necessary to cross-post between hotspot-dev and >>>>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>>>> >>>>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>>>> detector. >>>>>>> >>>>>>> Instead of registering the oop as an unhandled oop, which would have >>>>>>> worked, I decided to wrap the oop in a handle as long as it is on >>>>>>> the >>>>>>> stack. >>>>>>> >>>>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>>>> and oop >>>>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>>>> when >>>>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native >>>>>>> heap, copy >>>>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>>>> place/clear the >>>>>>> newly alloacted JvmtiBreakpoint in >>>>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>>>> >>>>>>> I have updated to the code to check that the public constructor >>>>>>> is only >>>>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>>>> programmer if he/she decides to allocate one on the heap). The >>>>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>>>> JvmtiBreakpoints. >>>>>>> >>>>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>>>> handle, >>>>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>>>> makes the oop in the handle safe for use after the >>>>>>> VM_ChangeBreakpoint >>>>>>> operation is finished. >>>>>>> >>>>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>>>> will be >>>>>>> visited by the GC via jvmtiExport::oops_do -> >>>>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is >>>>>>> being >>>>>>> added to. >>>>>>> >>>>>>> I've also removed some dead code to simplify the change: >>>>>>> - GrowableCache::insert >>>>>>> - JvmtiBreakpoint::copy >>>>>>> - JvmtiBreakpoint::lessThan >>>>>>> - GrowableElement::lessThan >>>>>>> >>>>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>>>> Jvmti::SetBreakpoint exactly the same to highlight that they >>>>>>> share all >>>>>>> code except one line. Unfortunately, I was not able to remove >>>>>>> this code >>>>>>> duplication in a good way. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>>>> jvmtiImpl.hpp: >>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>> by the VM operation, would it make sense to >>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>> >>>>>> 196 GrowableElement *clone() { >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>> _class_loader_handle); >>>>>> >>>>>> jvmtiImpl.cpp: >>>>>> No comments. >>>>>> >>>>>> jvmtiEnv.cpp: >>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>> ResourceMark or is it just not needed? >>>>>> - ResourceMark rm; >>>>>> + HandleMark hm; >>>>>> >>>>>> Otherwise the code change looks good. >>>>>> >>>>>> >>>>>> One thing that you didn't describe here, but which was related to >>>>>> the bug (which we discussed) was the fact that the old code tried to >>>>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>>>> added a Method*: >>>>>> >>>>>> thread->allow_unhandled_oop((oop*)&_method); >>>>>> >>>>>> We should take care to find other such places where we try to put a >>>>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>>>> the unhandled oops code. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> Testing: >>>>>>> - JPRT >>>>>>> - The four tests that were failing are now passing >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>>> >>>> >> > From stefan.karlsson at oracle.com Fri Oct 18 01:29:09 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Oct 2013 10:29:09 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131016160914.GA10865@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> Message-ID: <5260F155.4000107@oracle.com> On 2013-10-16 18:09, Erik Helin wrote: > Hi all, > > this patch fixes an issue where an oop in JvmtiBreakpoint, > JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > Instead of registering the oop as an unhandled oop, which would have > worked, I decided to wrap the oop in a handle as long as it is on the > stack. > > A JvmtiBreakpoint is created on the stack by the two methods > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > the values from the stack allocated JvmtiBreakpoint and then place/clear the > newly alloacted JvmtiBreakpoint in > JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > I have updated to the code to check that the public constructor is only > used to allocate JvmtiBreakpoints on the stack (to warn a future > programmer if he/she decides to allocate one on the heap). The > class_loader oop is now wrapped in a Handle for stack allocated > JvmtiBreakpoints. > > Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > the oops_do method of VM_ChangeBreakpoints can be removed. This also > makes the oop in the handle safe for use after the VM_ChangeBreakpoint > operation is finished. > > The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > visited by the GC via jvmtiExport::oops_do -> > JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > added to. > > I've also removed some dead code to simplify the change: > - GrowableCache::insert > - JvmtiBreakpoint::copy > - JvmtiBreakpoint::lessThan > - GrowableElement::lessThan > > Finally, I also formatted JvmtiEnv::ClearBreakpoint and > Jvmti::SetBreakpoint exactly the same to highlight that they share all > code except one line. Unfortunately, I was not able to remove this code > duplication in a good way. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ Not a review. I think there's a pre-existing bug in this code. Registering the class loader as a way to keep the Klass alive will not work for breakpoints in Anonymous Classes (JSR292). Anonymous classes have to register the mirror. See the code in the ClassLoaderData::is_alive: bool ClassLoaderData::is_alive(BoolObjectClosure* is_alive_closure) const { bool alive = is_anonymous() ? is_alive_closure->do_object_b(_klasses->java_mirror()) : class_loader() == NULL || is_alive_closure->do_object_b(class_loader()); assert(!alive || claimed(), "must be claimed"); return alive; } We probably want to add a function ClassLoaderData::keep_alive_oop() which returns the class loader for normal classes and the mirror for the anonymous classes, and use that in this and similar situations. StefanK > > Testing: > - JPRT > - The four tests that were failing are now passing > > Thanks, > Erik From erik.helin at oracle.com Fri Oct 18 03:56:44 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 18 Oct 2013 12:56:44 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260EB79.8080401@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> <5260EB79.8080401@oracle.com> Message-ID: <20131018105644.GA2408@ehelin-thinkpad> Hi David and Serguei, thanks for having a look at this change! On 2013-10-18, David Holmes wrote: > On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: > >On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: > >>On 10/17/13 11:03 PM, David Holmes wrote: > >>>On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: > >>>>Hi Erik, > >>>> > >>>>The fix looks good in general. > >>>> > >>>>But one thing is confusing in the fix. > >>>>Why do you keep both _class_loader and _class_loader_handle in the > >>>>JvmtiBreakpoint class? > >>> > >>>Even more confusing to me is the fact the neither of these seem to > >>>actually be used anywhere ??? > >> > >>Nice catch, David. > >>I do not see too any of them is really used. > >>Is it a leftover after the permgen elimination? > > > >Maybe this is a rush judging. > >It depends on the closure->do_oop() that is used for traversing > >I thought that the KeepAliveClosure is used below (basing on the comment). > > > >class JvmtiBreakpoint : public GrowableElement { > > . . . > > void oops_do(OopClosure* f) { > > // Mark the method loader as live > > f->do_oop(&_class_loader); > > } > > > >This oops_do() is not needed if we have handle instead of oop. > > Ah! Maybe the only purpose of keeping the class_loader (whether oop > or Handle) is that it is kept alive outside of its normal lifecycle. > > But still we should only need the Handle or the Oop, not both. And > if there is no oop we should not need an oops_do. I will try to explain the problem, the current implementation and then my change. The problem ----------- The problem is that JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint are passed a Method*. We must ensure that the class for this Method is kept alive by the GC. We do this by informing the GC that it must visit the class loader for the Method's class when marking. This can be done in two ways: - Putting a Handle on the stack containing an oop to the class loader - Have an oops_do method that we ensure will be called by the GC during marking A third option is to make sure (by inspecting the code) that no GC can occur that might cause problems, but this is a very brittle solution once a new programmer comes along and adds/removes code. The current implementation -------------------------- In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an "unhandled" oop to the class loader of the Method's class. A pointer to the JvmtiBreakpoint allocated on the stack will be passed to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. In the doit() method of VM_ChangeBreakpoint, JvmtiBreakpoints::set_at_safepoint will be called. A new JvmtiBreakpoint will be allocated on the heap by JvmtiBreakpoints::set_at_safepoint. The JvmtiBreakpoint on the heap will contain the same oop as the one in the JvmtiBreakpoint allocated on the stack earlier. The oop in the JvmtiBreakpoint allocated on the heap will be found by the GC, because VM_ChangeBreakpoint has an oops_do method (see first email for how this oops_do method is called). Once the VM_ChangeBreakpoint operation is done, then the JvmtiBreakpoint allocated on the heap will either be cleared due to a clear operation (and we do not care about the oop any longer) or it will be placed in JvmtiBreakpoints. JvmtiBreakpoints also has an oops_do which ensures that the oop now will be found by the GC. We will now pop the call stack and return to JvmtiEnv::SetBreakpoint or JvmtiEnv::ClearBreakpoint. No code in JvmtiEnv::SetBreakpoint or JvmtiEnv::ClearBreakpoint is touching the JvmtiBreakpoint after the VM_ChangeBreakpoint operation has been run. Furthermore, no GC can today occur before the call to VMThread::execute in JvmtiBreakpoints::set/clear. This means that the current implementation is safe, but understanding this is quite tricky. The change ---------- My proposed solution was the following: - When a JvmtiBreakpoint is allocated on the stack, place an oop to the Method's class loader in a Handle. - When a JvmtiBreakpoint is allocated on the heap, just store the oop to Method's class lodear in a field. The JvmtiBreakpoint will be placed in _jvmti_breakpoints which will be visited by the GC, which makes the GC call JvmtiBreakpoint::oops_do. Of course, this means that that if a GC occurs before the JvmtiBreakpoint in constructed in JvmtiEnv::SetBreakpoint or JvmtiEnv::ClearBreakpoint, the Method's class might be garbage collected. Ideally, we should wrap the Method* in jvmti_SetBreakpoint and jvmti_ClearBreakpoint in jvmtiEnter.cpp (a cpp file generated from an XML file via an XSL tranformation). As icing on the cake, if someone redefines the method that we are receiving a pointer to, then this code will probably not work at all. I believe (I am not sure) that this should be solved by having a MethodHandle wrapping the Method*. This change is just a first step towards safer code. I've gotten feedback internally that it is hard to understand the new code. I will try to see if I can update the change to make this clearer. Thanks for getting all the way to the end of this email :) Erik > David > > > > >> > >>> > >>>But if we have the Handle then the oop is redundant AFAICS. > >> > >>Right. > >>The issue is that the oop version is used in the oops_do. > >>Not sure if we can get rid of oops_do. > >>It may have an empty body though. > > > >Getting rid of the oops_do will require more cleanup that needs to be > >accurate. > > > > > >Thanks, > >Serguei > > > >> > >> > >>Thanks, > >>Serguei > >> > >>> > >>>David > >>> > >>>>Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > >>>>suites as well. > >>>> > >>>>Thanks, > >>>>Serguei > >>>> > >>>> > >>>>On 10/17/13 2:28 PM, Erik Helin wrote: > >>>>>Hi Mikael and Coleen, > >>>>> > >>>>>thanks for your reviews! > >>>>> > >>>>>On 2013-10-16, Mikael Gerdin wrote: > >>>>>>jvmtiImpl.hpp: > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > >>>>>>by the VM operation, would it make sense to > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > >>>>>> > >>>>>>196 GrowableElement *clone() { > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > >>>>>>_class_loader_handle); > >>>>>Agree, I've updated the patch. A new webrev is located at: > >>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ > >>>>> > >>>>>On 2013-10-16, Mikael Gerdin wrote: > >>>>>>jvmtiEnv.cpp: > >>>>>>Have you verified that the generated JVMTI entry point contains a > >>>>>>ResourceMark or is it just not needed? > >>>>>>- ResourceMark rm; > >>>>>>+ HandleMark hm; > >>>>>The JVMTI entry point does not contain a ResourceMark. However, I have > >>>>>verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint > >>>>>nor for jvmtiEnv::ClearBreapoint. The only codes that needs a > >>>>>ResourceMark is JvmtiBreakpoints::prints, but that method already > >>>>>has a > >>>>>ResourceMark. > >>>>> > >>>>>On 2013-10-16, Coleen Phillimore wrote: > >>>>>>Did you run the nsk.jvmti.testlist tests too though? > >>>>>No, I had not run the nsk.jvmti.testlist test, but I have now :) > >>>>> > >>>>>I run both with and without the patch on the latest hsx/hotspot-gc. I > >>>>>also run with and without -XX:+CheckUnhandledOops. The results were > >>>>>all > >>>>>the same: 598 passed an 11 failed (the same tests for all > >>>>>combinations). > >>>>>So, the patch does not introduce any regressions for this test suite. > >>>>> > >>>>>Thanks, > >>>>>Erik > >>>>> > >>>>>On 2013-10-16, Mikael Gerdin wrote: > >>>>>>Erik, > >>>>>> > >>>>>>(it's not necessary to cross-post between hotspot-dev and > >>>>>>hotspot-gc-dev, so I removed hotspot-gc from the CC list) > >>>>>> > >>>>>>On 2013-10-16 18:09, Erik Helin wrote: > >>>>>>>Hi all, > >>>>>>> > >>>>>>>this patch fixes an issue where an oop in JvmtiBreakpoint, > >>>>>>>JvmtiBreakpoint::_class_loader, was found by the unhandled oop > >>>>>>>detector. > >>>>>>> > >>>>>>>Instead of registering the oop as an unhandled oop, which would have > >>>>>>>worked, I decided to wrap the oop in a handle as long as it is on > >>>>>>>the > >>>>>>>stack. > >>>>>>> > >>>>>>>A JvmtiBreakpoint is created on the stack by the two methods > >>>>>>>JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > >>>>>>>JvmtiBreakpoint is only created to carry the Method*, jlocation > >>>>>>>and oop > >>>>>>>to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, > >>>>>>>when > >>>>>>>at a safepoint, allocate a new JvmtiBreakpoint on the native > >>>>>>>heap, copy > >>>>>>>the values from the stack allocated JvmtiBreakpoint and then > >>>>>>>place/clear the > >>>>>>>newly alloacted JvmtiBreakpoint in > >>>>>>>JvmtiCurrentBreakpoints::_jvmti_breakpoints. > >>>>>>> > >>>>>>>I have updated to the code to check that the public constructor > >>>>>>>is only > >>>>>>>used to allocate JvmtiBreakpoints on the stack (to warn a future > >>>>>>>programmer if he/she decides to allocate one on the heap). The > >>>>>>>class_loader oop is now wrapped in a Handle for stack allocated > >>>>>>>JvmtiBreakpoints. > >>>>>>> > >>>>>>>Due to the stack allocated JvmtiBreakpoint having the oop in a > >>>>>>>handle, > >>>>>>>the oops_do method of VM_ChangeBreakpoints can be removed. This also > >>>>>>>makes the oop in the handle safe for use after the > >>>>>>>VM_ChangeBreakpoint > >>>>>>>operation is finished. > >>>>>>> > >>>>>>>The unhandled oop in the JvmtiBreakpoint allocated on the heap > >>>>>>>will be > >>>>>>>visited by the GC via jvmtiExport::oops_do -> > >>>>>>>JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > >>>>>>>GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is > >>>>>>>being > >>>>>>>added to. > >>>>>>> > >>>>>>>I've also removed some dead code to simplify the change: > >>>>>>>- GrowableCache::insert > >>>>>>>- JvmtiBreakpoint::copy > >>>>>>>- JvmtiBreakpoint::lessThan > >>>>>>>- GrowableElement::lessThan > >>>>>>> > >>>>>>>Finally, I also formatted JvmtiEnv::ClearBreakpoint and > >>>>>>>Jvmti::SetBreakpoint exactly the same to highlight that they > >>>>>>>share all > >>>>>>>code except one line. Unfortunately, I was not able to remove > >>>>>>>this code > >>>>>>>duplication in a good way. > >>>>>>> > >>>>>>>Webrev: > >>>>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > >>>>>>jvmtiImpl.hpp: > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > >>>>>>by the VM operation, would it make sense to > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > >>>>>> > >>>>>>196 GrowableElement *clone() { > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > >>>>>>_class_loader_handle); > >>>>>> > >>>>>>jvmtiImpl.cpp: > >>>>>>No comments. > >>>>>> > >>>>>>jvmtiEnv.cpp: > >>>>>>Have you verified that the generated JVMTI entry point contains a > >>>>>>ResourceMark or is it just not needed? > >>>>>>- ResourceMark rm; > >>>>>>+ HandleMark hm; > >>>>>> > >>>>>>Otherwise the code change looks good. > >>>>>> > >>>>>> > >>>>>>One thing that you didn't describe here, but which was related to > >>>>>>the bug (which we discussed) was the fact that the old code tried to > >>>>>>"do the right thing" WRT CheckUnhandledOops, but it incorrectly > >>>>>>added a Method*: > >>>>>> > >>>>>>thread->allow_unhandled_oop((oop*)&_method); > >>>>>> > >>>>>>We should take care to find other such places where we try to put a > >>>>>>non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in > >>>>>>the unhandled oops code. > >>>>>> > >>>>>>/Mikael > >>>>>> > >>>>>>>Testing: > >>>>>>>- JPRT > >>>>>>>- The four tests that were failing are now passing > >>>>>>> > >>>>>>>Thanks, > >>>>>>>Erik > >>>>>>> > >>>> > >> > > From staffan.larsen at oracle.com Fri Oct 18 04:02:29 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 13:02:29 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FD384.4010904@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> <525FC4F8.1020004@oracle.com> <525FD384.4010904@oracle.com> Message-ID: Looks good to me. Thanks, /Staffan On 17 okt 2013, at 14:09, Jaroslav Bachorik wrote: > On 17.10.2013 13:07, David Holmes wrote: >> On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: >>> Hi David, >>> >>> On 17.10.2013 04:26, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> Minor nit: os::elapsed_time should really be defined in terms of the >>>> other functions ie: >>>> >>>> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); >>> >>> Ok. I've changed it. It better communicates the way the elapsedTime is >>> calculated anyway. >>> >>>> >>>> I also prefer the cast above as it is very clear that we will be doing a >>>> floating-point division. >>>> >>>> Aside: AFAICS os::elapsed_time() is never actually used ?? >>> >>> Actually, it is os::elapsedTime() and this one is used quite a lot. The >>> "elapsed_time()" form is used only in bytecodeHistogram.hpp, >>> parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. >> >> AFAICS they all define their own elapsed_time() functions they don't use >> os::elapsed_time(). >> >>>> >>>> I agree that it appears that changing the frequency should be okay. >>> >>> Thanks for the feedback. >>> >>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >> >> That should be .04 version :) > > Yep :( copy-paste ... > http://cr.openjdk.java.net/~jbachorik/6523160/webrev.04 > >> >> Looks okay. >> >> Thanks, >> David >> >>> -JB- >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>>>> On 15.10.2013 08:49, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> os_bsd.cpp / os_linux.cpp: >>>>>> >>>>>> If you don't have a monotonic clock you leave timer_frequency set >>>>>> to 0! >>>>>> (So you need to test on a system without a monotonic clock, or else >>>>>> force it to act as-if not present.) >>>>>> >>>>>> That aside I don't trust clock_getres to give values that actually >>>>>> allow >>>>>> the timer frequency to be determined. As per the comments in >>>>>> os_linux.cpp: >>>>>> >>>>>> // It's fixed in newer kernels, however clock_getres() still returns >>>>>> // 1/HZ. We check if clock_getres() works, but will ignore its >>>>>> reported >>>>>> // resolution for now. Hopefully as people move to new kernels, this >>>>>> // won't be a problem. >>>>>> >>>>>> we don't know what kernels provide real values here and which provide >>>>>> dummy ones. >>>>>> >>>>>> On BSD you haven't modified os::elapsed_counter. >>>>>> >>>>>> Looking at the linux changes I don't think the logic is correct >>>>>> even if >>>>>> clock_getres is accurate. In the existing code we have: >>>>>> >>>>>> elapsed_counter -> elapsed time in microseconds >>>>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>>>> >>>>>> Now we have: >>>>>> >>>>>> elapsed_counter -> elapsed time in nanoseconds >>>>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>>>> elapsed_time -> counter/frequency -> ??? >>>>>> >>>>>> So elapsed_time not, in general, going to give the elapsed time in >>>>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>>>> "time" in nanoseconds. >>>>>> >>>>>> >>>>>> Also note that we constants for: >>>>>> >>>>>> NANOSECS_PER_SEC >>>>>> NANOSECS_PER_MILLISEC >>>>>> >>>>>> to aid with time conversions. >>>>>> >>>>>> The linux webrev contains unrelated UseLargePages changes! >>>>> >>>>> Sorry for the mess with UseLargePages changes :/ >>>>> >>>>> I've fixed the problems with the frequency (using a fixed number as >>>>> before) and I kept the changes to minimum. >>>>> >>>>> I was hesitating about changing the elapsed_counter precision from >>>>> microseconds to nanoseconds but since solaris and windows versions >>>>> already use nanosecond ticks for elapsed_counter I think the change is >>>>> safe. >>>>> >>>>> The update webrev: >>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>>>> >>>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>>>> >>>>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>>>> >>>>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>>>> >>>>>>>>>>>>> This discussion also implies that the "elapsed time" we >>>>>>>>>>>>> print in >>>>>>>>>>>>> the >>>>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>>> >>>>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>>>> (class VMUptimeDCmd) which also relies on >>>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>> >>>>>>>>>>>> Also the reported GC pauses duration might be wrong since it >>>>>>>>>>>> uses >>>>>>>>>>>> Management::timestamp(). >>>>>>>>>>>> >>>>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>>>> honestly, >>>>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>>>> once >>>>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>>>> equivalent. >>>>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>>>> >>>>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>>>> current >>>>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>>>> few >>>>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>>>> before >>>>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>>>> >>>>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>>>> the >>>>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>>>> first 8 >>>>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>>>> right >>>>>>>>>>> now. >>>>>>>>>> >>>>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>>>> been >>>>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>>>> (yes a >>>>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>>>> modified >>>>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>>>> to be >>>>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>>>> attempted >>>>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>>>> based >>>>>>>>>> timestamp with the TOD. :( >>>>>>>>> >>>>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>>>> value. It >>>>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>>>> For Linux/BSD the TOD is used directly. >>>>>>>>> >>>>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>>>> follow the same logic would be really that disruptive. >>>>>>>> >>>>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>>>> interesting experiment. >>>>>>> >>>>>>> The change is rather simple and tests ok. All the means to get a >>>>>>> monotonic timestamp are already there and proved to work. The core >>>>>>> tests >>>>>>> in JPRT went fine. >>>>>>> >>>>>>> The updated webrev is at >>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday >>>>>>>>>>>>>>>>> so is >>>>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>>>> make me >>>>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>>>> because of >>>>>>>>>>>>>>> the way these are used in logging etc. Certainly not >>>>>>>>>>>>>>> something >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> can then >>>>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks >>>>>>>>>>>>>> where >>>>>>>>>>>>>> possible. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Fri Oct 18 07:29:42 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Oct 2013 10:29:42 -0400 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260F155.4000107@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <5260F155.4000107@oracle.com> Message-ID: <526145D6.1040601@oracle.com> Stefan is right. We should be saving the result of this: // Oop that keeps the metadata for this class from being unloaded // in places where the metadata is stored in other places, like nmethods oop klass_holder() const { return is_anonymous() ? java_mirror() : class_loader(); } This was implemented before anonymous classes, where we used to use the class loader to keep any metadata that we store alive. We did this preemptively in this case. If the class loader cannot be reclaimed while these jvmtiBreakpoint classes are alive (ie. there is always a mirror or instance of the class around), we probably don't need this code at all. But I don't know if this is proveable. Potentially the stack cases of this, it might be, just not the allocated case? thanks, Coleen On 10/18/2013 04:29 AM, Stefan Karlsson wrote: > On 2013-10-16 18:09, Erik Helin wrote: >> Hi all, >> >> this patch fixes an issue where an oop in JvmtiBreakpoint, >> JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. >> >> Instead of registering the oop as an unhandled oop, which would have >> worked, I decided to wrap the oop in a handle as long as it is on the >> stack. >> >> A JvmtiBreakpoint is created on the stack by the two methods >> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >> JvmtiBreakpoint is only created to carry the Method*, jlocation and oop >> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when >> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy >> the values from the stack allocated JvmtiBreakpoint and then >> place/clear the >> newly alloacted JvmtiBreakpoint in >> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >> >> I have updated to the code to check that the public constructor is only >> used to allocate JvmtiBreakpoints on the stack (to warn a future >> programmer if he/she decides to allocate one on the heap). The >> class_loader oop is now wrapped in a Handle for stack allocated >> JvmtiBreakpoints. >> >> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >> the oops_do method of VM_ChangeBreakpoints can be removed. This also >> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >> operation is finished. >> >> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >> visited by the GC via jvmtiExport::oops_do -> >> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >> added to. >> >> I've also removed some dead code to simplify the change: >> - GrowableCache::insert >> - JvmtiBreakpoint::copy >> - JvmtiBreakpoint::lessThan >> - GrowableElement::lessThan >> >> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >> Jvmti::SetBreakpoint exactly the same to highlight that they share all >> code except one line. Unfortunately, I was not able to remove this code >> duplication in a good way. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > Not a review. > > I think there's a pre-existing bug in this code. Registering the class > loader as a way to keep the Klass alive will not work for breakpoints > in Anonymous Classes (JSR292). Anonymous classes have to register the > mirror. See the code in the ClassLoaderData::is_alive: > > bool ClassLoaderData::is_alive(BoolObjectClosure* is_alive_closure) > const { > bool alive = > is_anonymous() ? > is_alive_closure->do_object_b(_klasses->java_mirror()) : > class_loader() == NULL || > is_alive_closure->do_object_b(class_loader()); > assert(!alive || claimed(), "must be claimed"); > return alive; > } > > We probably want to add a function ClassLoaderData::keep_alive_oop() > which returns the class loader for normal classes and the mirror for > the anonymous classes, and use that in this and similar situations. > > StefanK > >> >> Testing: >> - JPRT >> - The four tests that were failing are now passing >> >> Thanks, >> Erik > From john.coomes at oracle.com Fri Oct 18 16:24:26 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Oct 2013 23:24:26 +0000 Subject: hg: hsx/hotspot-main/hotspot: 17 new changesets Message-ID: <20131018232507.20D196255B@hg.openjdk.java.net> Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java From wangshuai901 at gmail.com Fri Oct 18 21:52:12 2013 From: wangshuai901 at gmail.com (Shuai Wang) Date: Sat, 19 Oct 2013 00:52:12 -0400 Subject: What does certain JVM do after loading ByteCode into memory? Message-ID: Like HotSpot.. I stopped its complied mode and I was thinking ByteCode of classes should be in the memory by the opcode presents.. But it seems I am wrong.. and some experts told me that there should be some transformation processes when loading ByteCode into memory.. Could any body give me more instructions about this issue...? Thank you a lot! From alejandro.murillo at oracle.com Sat Oct 19 00:58:11 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 19 Oct 2013 07:58:11 +0000 Subject: hg: hsx/hsx25/hotspot: 68 new changesets Message-ID: <20131019080103.2C39962569@hg.openjdk.java.net> Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e831448418ac Merge Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/301ece1880ad Merge Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/26ae62bc26c4 Merge Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df268195b0ea Merge Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/83dbf427fedd Merge Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e8703d708e6e Merge Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5f1241525a01 Merge Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dd2cf1d1248b Merge Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ed2c74787eb5 Merge Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1263c7e17e1c Merge Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags From alejandro.murillo at oracle.com Sat Oct 19 17:32:52 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sun, 20 Oct 2013 00:32:52 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131020003304.05C9F62578@hg.openjdk.java.net> Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags Changeset: d6d8aeb2c2d4 Author: amurillo Date: 2013-10-19 08:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d6d8aeb2c2d4 8026928: new hotspot build - hs25-b56 Reviewed-by: jcoomes ! make/hotspot_version From david.dehaven at oracle.com Sun Oct 20 16:56:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Sun, 20 Oct 2013 16:56:13 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit Message-ID: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> CCing: build-dev, macosx-port-dev, hotspot-dev Request for review of JDK-8025673: https://bugs.openjdk.java.net/browse/JDK-8025673 Proposed changes: http://cr.openjdk.java.net/~ddehaven/8025673/ This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. Significant build system changes, build-dev guys are encouraged to comment... I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. Question for the AWT team, we still have this in java_props_md.c: 458 PreferredToolkit prefToolkit = getPreferredToolkit(); 459 if (prefToolkit == CToolkit) { 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; 461 } else { 462 // TODO: do we still need this? 463 sprops.awt_toolkit = "sun.awt.HToolkit"; 464 } Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. -DrD- From david.holmes at oracle.com Sun Oct 20 23:42:58 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Oct 2013 16:42:58 +1000 Subject: XXS: RFR 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Message-ID: <5264CCF2.6070001@oracle.com> The precompiled classes used by these tests are defined to extend java.applet.Applet and so require a full JRE for execution. These tests (which were recently renamed and converted to Java from a sh script) need to be added to the :needs_jre group in TEST.groups. Testing for this issue also found another missing group entry: gc/metaspace/TestPerfCountersAndMemoryPools.java - needs_jdk webrev: http://cr.openjdk.java.net/~dholmes/8026872/webrev/ Thanks, David From erik.joelsson at oracle.com Mon Oct 21 01:31:31 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Oct 2013 10:31:31 +0200 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <5264E663.7050401@oracle.com> Hello David, From a build point of view, the changes look fine to me. /Erik On 2013-10-21 01:56, David DeHaven wrote: > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. > > > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From erik.helin at oracle.com Mon Oct 21 01:48:32 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 21 Oct 2013 10:48:32 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131018105644.GA2408@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> <5260EB79.8080401@oracle.com> <20131018105644.GA2408@ehelin-thinkpad> Message-ID: <20131021084832.GC2608@ehelin-thinkpad> All, after having discussed this issue some more, I've decided to split it into multiple issues: - The crash when using -XX:+CheckUnhandledOops - Using MethodHandle instead of Method* - Using java_mirror() for anonymous classes I will send out a new webrev with a much smaller change that only solves the first issue (the crash with -XX:+CheckUnhandledOops). This review request will be labeled (round 2) as in: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2). For the other two issues, I have created the following two bugs: - https://bugs.openjdk.java.net/browse/JDK-8026946 - https://bugs.openjdk.java.net/browse/JDK-8026948 Everyone, thanks for all your feedback on this change! Erik On 2013-10-18, Erik Helin wrote: > Hi David and Serguei, > > thanks for having a look at this change! > > On 2013-10-18, David Holmes wrote: > > On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: > > >On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: > > >>On 10/17/13 11:03 PM, David Holmes wrote: > > >>>On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: > > >>>>Hi Erik, > > >>>> > > >>>>The fix looks good in general. > > >>>> > > >>>>But one thing is confusing in the fix. > > >>>>Why do you keep both _class_loader and _class_loader_handle in the > > >>>>JvmtiBreakpoint class? > > >>> > > >>>Even more confusing to me is the fact the neither of these seem to > > >>>actually be used anywhere ??? > > >> > > >>Nice catch, David. > > >>I do not see too any of them is really used. > > >>Is it a leftover after the permgen elimination? > > > > > >Maybe this is a rush judging. > > >It depends on the closure->do_oop() that is used for traversing > > >I thought that the KeepAliveClosure is used below (basing on the comment). > > > > > >class JvmtiBreakpoint : public GrowableElement { > > > . . . > > > void oops_do(OopClosure* f) { > > > // Mark the method loader as live > > > f->do_oop(&_class_loader); > > > } > > > > > >This oops_do() is not needed if we have handle instead of oop. > > > > Ah! Maybe the only purpose of keeping the class_loader (whether oop > > or Handle) is that it is kept alive outside of its normal lifecycle. > > > > But still we should only need the Handle or the Oop, not both. And > > if there is no oop we should not need an oops_do. > > I will try to explain the problem, the current implementation and then > my change. > > The problem > ----------- > > The problem is that JvmtiEnv::SetBreakpoint and > JvmtiEnv::ClearBreakpoint are passed a Method*. We must ensure that the > class for this Method is kept alive by the GC. We do this by informing > the GC that it must visit the class loader for the Method's class when > marking. This can be done in two ways: > - Putting a Handle on the stack containing an oop to the class loader > - Have an oops_do method that we ensure will be called by the GC during > marking > > A third option is to make sure (by inspecting the code) that no GC can > occur that might cause problems, but this is a very brittle solution > once a new programmer comes along and adds/removes code. > > The current implementation > -------------------------- > > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. > In the doit() method of VM_ChangeBreakpoint, > JvmtiBreakpoints::set_at_safepoint will be called. A new JvmtiBreakpoint > will be allocated on the heap by JvmtiBreakpoints::set_at_safepoint. > > The JvmtiBreakpoint on the heap will contain the same oop as the one in > the JvmtiBreakpoint allocated on the stack earlier. The oop in the > JvmtiBreakpoint allocated on the heap will be found by the GC, because > VM_ChangeBreakpoint has an oops_do method (see first email for how this > oops_do method is called). > > Once the VM_ChangeBreakpoint operation is done, then the JvmtiBreakpoint > allocated on the heap will either be cleared due to a clear operation > (and we do not care about the oop any longer) or it will be placed in > JvmtiBreakpoints. JvmtiBreakpoints also has an oops_do which ensures > that the oop now will be found by the GC. > > We will now pop the call stack and return to JvmtiEnv::SetBreakpoint or > JvmtiEnv::ClearBreakpoint. No code in JvmtiEnv::SetBreakpoint or > JvmtiEnv::ClearBreakpoint is touching the JvmtiBreakpoint after the > VM_ChangeBreakpoint operation has been run. > > Furthermore, no GC can today occur before the call to VMThread::execute > in JvmtiBreakpoints::set/clear. > > This means that the current implementation is safe, but understanding > this is quite tricky. > > The change > ---------- > > My proposed solution was the following: > - When a JvmtiBreakpoint is allocated on the stack, place an oop to the > Method's class loader in a Handle. > - When a JvmtiBreakpoint is allocated on the heap, just store the oop to > Method's class lodear in a field. The JvmtiBreakpoint will be placed > in _jvmti_breakpoints which will be visited by the GC, which makes the > GC call JvmtiBreakpoint::oops_do. > > Of course, this means that that if a GC occurs before the > JvmtiBreakpoint in constructed in JvmtiEnv::SetBreakpoint or > JvmtiEnv::ClearBreakpoint, the Method's class might be garbage > collected. Ideally, we should wrap the Method* in jvmti_SetBreakpoint > and jvmti_ClearBreakpoint in jvmtiEnter.cpp (a cpp file generated from > an XML file via an XSL tranformation). > > As icing on the cake, if someone redefines the method that we are > receiving a pointer to, then this code will probably not work at all. I > believe (I am not sure) that this should be solved by having a > MethodHandle wrapping the Method*. > > This change is just a first step towards safer code. > > I've gotten feedback internally that it is hard to understand the > new code. I will try to see if I can update the change to make this > clearer. > > Thanks for getting all the way to the end of this email :) > > Erik > > > David > > > > > > > >> > > >>> > > >>>But if we have the Handle then the oop is redundant AFAICS. > > >> > > >>Right. > > >>The issue is that the oop version is used in the oops_do. > > >>Not sure if we can get rid of oops_do. > > >>It may have an empty body though. > > > > > >Getting rid of the oops_do will require more cleanup that needs to be > > >accurate. > > > > > > > > >Thanks, > > >Serguei > > > > > >> > > >> > > >>Thanks, > > >>Serguei > > >> > > >>> > > >>>David > > >>> > > >>>>Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > > >>>>suites as well. > > >>>> > > >>>>Thanks, > > >>>>Serguei > > >>>> > > >>>> > > >>>>On 10/17/13 2:28 PM, Erik Helin wrote: > > >>>>>Hi Mikael and Coleen, > > >>>>> > > >>>>>thanks for your reviews! > > >>>>> > > >>>>>On 2013-10-16, Mikael Gerdin wrote: > > >>>>>>jvmtiImpl.hpp: > > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > > >>>>>>by the VM operation, would it make sense to > > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > > >>>>>> > > >>>>>>196 GrowableElement *clone() { > > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > > >>>>>>_class_loader_handle); > > >>>>>Agree, I've updated the patch. A new webrev is located at: > > >>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ > > >>>>> > > >>>>>On 2013-10-16, Mikael Gerdin wrote: > > >>>>>>jvmtiEnv.cpp: > > >>>>>>Have you verified that the generated JVMTI entry point contains a > > >>>>>>ResourceMark or is it just not needed? > > >>>>>>- ResourceMark rm; > > >>>>>>+ HandleMark hm; > > >>>>>The JVMTI entry point does not contain a ResourceMark. However, I have > > >>>>>verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint > > >>>>>nor for jvmtiEnv::ClearBreapoint. The only codes that needs a > > >>>>>ResourceMark is JvmtiBreakpoints::prints, but that method already > > >>>>>has a > > >>>>>ResourceMark. > > >>>>> > > >>>>>On 2013-10-16, Coleen Phillimore wrote: > > >>>>>>Did you run the nsk.jvmti.testlist tests too though? > > >>>>>No, I had not run the nsk.jvmti.testlist test, but I have now :) > > >>>>> > > >>>>>I run both with and without the patch on the latest hsx/hotspot-gc. I > > >>>>>also run with and without -XX:+CheckUnhandledOops. The results were > > >>>>>all > > >>>>>the same: 598 passed an 11 failed (the same tests for all > > >>>>>combinations). > > >>>>>So, the patch does not introduce any regressions for this test suite. > > >>>>> > > >>>>>Thanks, > > >>>>>Erik > > >>>>> > > >>>>>On 2013-10-16, Mikael Gerdin wrote: > > >>>>>>Erik, > > >>>>>> > > >>>>>>(it's not necessary to cross-post between hotspot-dev and > > >>>>>>hotspot-gc-dev, so I removed hotspot-gc from the CC list) > > >>>>>> > > >>>>>>On 2013-10-16 18:09, Erik Helin wrote: > > >>>>>>>Hi all, > > >>>>>>> > > >>>>>>>this patch fixes an issue where an oop in JvmtiBreakpoint, > > >>>>>>>JvmtiBreakpoint::_class_loader, was found by the unhandled oop > > >>>>>>>detector. > > >>>>>>> > > >>>>>>>Instead of registering the oop as an unhandled oop, which would have > > >>>>>>>worked, I decided to wrap the oop in a handle as long as it is on > > >>>>>>>the > > >>>>>>>stack. > > >>>>>>> > > >>>>>>>A JvmtiBreakpoint is created on the stack by the two methods > > >>>>>>>JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > > >>>>>>>JvmtiBreakpoint is only created to carry the Method*, jlocation > > >>>>>>>and oop > > >>>>>>>to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, > > >>>>>>>when > > >>>>>>>at a safepoint, allocate a new JvmtiBreakpoint on the native > > >>>>>>>heap, copy > > >>>>>>>the values from the stack allocated JvmtiBreakpoint and then > > >>>>>>>place/clear the > > >>>>>>>newly alloacted JvmtiBreakpoint in > > >>>>>>>JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > >>>>>>> > > >>>>>>>I have updated to the code to check that the public constructor > > >>>>>>>is only > > >>>>>>>used to allocate JvmtiBreakpoints on the stack (to warn a future > > >>>>>>>programmer if he/she decides to allocate one on the heap). The > > >>>>>>>class_loader oop is now wrapped in a Handle for stack allocated > > >>>>>>>JvmtiBreakpoints. > > >>>>>>> > > >>>>>>>Due to the stack allocated JvmtiBreakpoint having the oop in a > > >>>>>>>handle, > > >>>>>>>the oops_do method of VM_ChangeBreakpoints can be removed. This also > > >>>>>>>makes the oop in the handle safe for use after the > > >>>>>>>VM_ChangeBreakpoint > > >>>>>>>operation is finished. > > >>>>>>> > > >>>>>>>The unhandled oop in the JvmtiBreakpoint allocated on the heap > > >>>>>>>will be > > >>>>>>>visited by the GC via jvmtiExport::oops_do -> > > >>>>>>>JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > > >>>>>>>GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is > > >>>>>>>being > > >>>>>>>added to. > > >>>>>>> > > >>>>>>>I've also removed some dead code to simplify the change: > > >>>>>>>- GrowableCache::insert > > >>>>>>>- JvmtiBreakpoint::copy > > >>>>>>>- JvmtiBreakpoint::lessThan > > >>>>>>>- GrowableElement::lessThan > > >>>>>>> > > >>>>>>>Finally, I also formatted JvmtiEnv::ClearBreakpoint and > > >>>>>>>Jvmti::SetBreakpoint exactly the same to highlight that they > > >>>>>>>share all > > >>>>>>>code except one line. Unfortunately, I was not able to remove > > >>>>>>>this code > > >>>>>>>duplication in a good way. > > >>>>>>> > > >>>>>>>Webrev: > > >>>>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > >>>>>>jvmtiImpl.hpp: > > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > > >>>>>>by the VM operation, would it make sense to > > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > > >>>>>> > > >>>>>>196 GrowableElement *clone() { > > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > > >>>>>>_class_loader_handle); > > >>>>>> > > >>>>>>jvmtiImpl.cpp: > > >>>>>>No comments. > > >>>>>> > > >>>>>>jvmtiEnv.cpp: > > >>>>>>Have you verified that the generated JVMTI entry point contains a > > >>>>>>ResourceMark or is it just not needed? > > >>>>>>- ResourceMark rm; > > >>>>>>+ HandleMark hm; > > >>>>>> > > >>>>>>Otherwise the code change looks good. > > >>>>>> > > >>>>>> > > >>>>>>One thing that you didn't describe here, but which was related to > > >>>>>>the bug (which we discussed) was the fact that the old code tried to > > >>>>>>"do the right thing" WRT CheckUnhandledOops, but it incorrectly > > >>>>>>added a Method*: > > >>>>>> > > >>>>>>thread->allow_unhandled_oop((oop*)&_method); > > >>>>>> > > >>>>>>We should take care to find other such places where we try to put a > > >>>>>>non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in > > >>>>>>the unhandled oops code. > > >>>>>> > > >>>>>>/Mikael > > >>>>>> > > >>>>>>>Testing: > > >>>>>>>- JPRT > > >>>>>>>- The four tests that were failing are now passing > > >>>>>>> > > >>>>>>>Thanks, > > >>>>>>>Erik > > >>>>>>> > > >>>> > > >> > > > From staffan.larsen at oracle.com Mon Oct 21 02:03:36 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Oct 2013 11:03:36 +0200 Subject: XXS: RFR 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles In-Reply-To: <5264CCF2.6070001@oracle.com> References: <5264CCF2.6070001@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 21 okt 2013, at 08:42, David Holmes wrote: > The precompiled classes used by these tests are defined to extend java.applet.Applet and so require a full JRE for execution. These tests (which were recently renamed and converted to Java from a sh script) need to be added to the :needs_jre group in TEST.groups. > > Testing for this issue also found another missing group entry: > > gc/metaspace/TestPerfCountersAndMemoryPools.java - needs_jdk > > webrev: > > http://cr.openjdk.java.net/~dholmes/8026872/webrev/ > > Thanks, > David From erik.helin at oracle.com Mon Oct 21 02:26:51 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 21 Oct 2013 11:26:51 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) Message-ID: <20131021092651.GD2608@ehelin-thinkpad> Hi all, this is the second version of a patch for JDK-8025834. Background: In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an "unhandled" oop to the class loader of the Method's class. A pointer to the JvmtiBreakpoint allocated on the stack will be passed to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The VM_ChangeBreakpoint class has an oops_do method that will visit the oop in the JvmtiBreakpoint that was allocated on the stack. Since no GC can occur before the JvmtiBreakpoint has been passed to the VM_ChangeBreakpoint (which is then passed to VMThread::execute), there is no need to have a Handle for the _class_loader oop. Once the VM_ChangeBreakpoint is on the VMThread's list for being executed, the oop will be found via VMThread::oops_do. The oop can't be changed to a Handle because JvmtiBreakpoint:s are also allocated on the heap, and Handles are only used for oops allocated on the stack. This patch therefore registers the oop as "unhandled" to tell the unhandled oop verifier to (rightfully) ignore it. Webrev: http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025834 As I explained in a previous email, there are additional issues in the JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: - https://bugs.openjdk.java.net/browse/JDK-8026946 - https://bugs.openjdk.java.net/browse/JDK-8026948 This change does not intend to fix these issues. Thanks, Erik From artem.ananiev at oracle.com Mon Oct 21 02:35:39 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 Oct 2013 13:35:39 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <5264F56B.6030100@oracle.com> Hi, David, the changes look fine to me. See more comments below. On 10/21/2013 3:56 AM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. This question is for SE embedded team and for people who are responsible for reduced JRE builds, when some native libraries (including libawt_lwawt) are stripped. If these reduced builds are only for Solaris/Linux, then we don't need HToolkit stuff on Mac. Thanks, Artem > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From mikael.gerdin at oracle.com Mon Oct 21 04:07:02 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 21 Oct 2013 13:07:02 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <2541260.D7TBTJESY6@mgerdin03> Erik, On Monday 21 October 2013 11.26.51 Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ The change looks good to me. /Mikael > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik From david.holmes at oracle.com Mon Oct 21 04:38:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Oct 2013 21:38:18 +1000 Subject: Solaris fastdebug build: gobjcopy? In-Reply-To: <5264ED10.7000308@oracle.com> References: <5264ED10.7000308@oracle.com> Message-ID: <5265122A.30101@oracle.com> Hi Max, On 21/10/2013 7:00 PM, Weijun Wang wrote: > Hi All > > I'm trying --enable-debug on a Solaris and see this failure > > ## Starting hotspot > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/sfw/bin/gobjcopy > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/sfw/bin/gobjcopy > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > Rescanned ../generated/adfiles/solaris_x86_64.ad but encountered no > changes. > Making signal interposition lib... > Opening 'libjsig.so' for update > No SHF_ALLOC flags needed to be cleared. > Done with 'libjsig.so' > make381[6]: /usr/sfw/bin/gobjcopy: Command not found > make381[6]: *** [libjsig.so] Error 127 > make381[5]: *** [the_vm] Error 2 > > Where can I install the gobjcopy command? This is a "SunOS s11 5.11 > snv_151a" machine. I remember I just copy SS12U1 from somewhere else, > put its bin into $PATH, and start building. > > Also, the output above seems to say that gobjcopy is not found so > ENABLE_FULL_DEBUG_SYMBOLS falls back to 0 and the build could go on. Why > does it fail again with the same problem? Not sure - that seems to be a bug in the hotspot build (hence cc hotspot-dev). The FDS logic is processed multiple times but the initial pass should disable FDS for the subsequent uses. If gobjcopy is installed somewhere then ALT_OBJCOPY can be set to point to it. Was this part of a full build? The configure process might also find gobjcopy and set the appropriate variables. David > Thanks > Max From weijun.wang at oracle.com Mon Oct 21 05:28:15 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Oct 2013 20:28:15 +0800 Subject: Solaris fastdebug build: gobjcopy? In-Reply-To: <5265122A.30101@oracle.com> References: <5264ED10.7000308@oracle.com> <5265122A.30101@oracle.com> Message-ID: <52651DDF.9050000@oracle.com> This is a full build, but I run configure on one machine and make from another. Doing both on the same machine without gobjcopy runs fine. Thanks Max On 10/21/13 7:38 PM, David Holmes wrote: > If gobjcopy is > installed somewhere then ALT_OBJCOPY can be set to point to it. Was this > part of a full build? The configure process might also find gobjcopy and > set the appropriate variables. > > David > >> Thanks >> Max From erik.helin at oracle.com Mon Oct 21 05:36:14 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 21 Oct 2013 14:36:14 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <2541260.D7TBTJESY6@mgerdin03> References: <20131021092651.GD2608@ehelin-thinkpad> <2541260.D7TBTJESY6@mgerdin03> Message-ID: <20131021123614.GA10430@ehelin-thinkpad> Hi Mikael, thanks for reviewing! Based on internal feedback, I've updated the comment slightly: diff --git a/src/share/vm/prims/jvmtiImpl.cpp b/src/share/vm/prims/jvmtiImpl.cpp --- a/src/share/vm/prims/jvmtiImpl.cpp +++ b/src/share/vm/prims/jvmtiImpl.cpp @@ -225,18 +225,20 @@ _method = NULL; _bci = 0; _class_loader = NULL; -#ifdef CHECK_UNHANDLED_OOPS - // This one is always allocated with new, but check it just in case. - Thread *thread = Thread::current(); - if (thread->is_in_stack((address)&_method)) { - thread->allow_unhandled_oop((oop*)&_method); - } -#endif // CHECK_UNHANDLED_OOPS } JvmtiBreakpoint::JvmtiBreakpoint(Method* m_method, jlocation location) { _method = m_method; _class_loader = _method->method_holder()->class_loader_data()->class_loader(); +#ifdef CHECK_UNHANDLED_OOPS + // _class_loader can't be wrapped in a Handle, because JvmtiBreakpoint:s are + // eventually allocated on the heap. + // + // The code handling JvmtiBreakpoint:s allocated on the stack can't be + // interrupted by a GC until _class_loader is reachable by the GC via the + // oops_do method. + Thread::current()->allow_unhandled_oop(&_class_loader); +#endif // CHECK_UNHANDLED_OOPS assert(_method != NULL, "_method != NULL"); _bci = (int) location; assert(_bci >= 0, "_bci >= 0"); What do you think? Thanks, Erik On 2013-10-21, Mikael Gerdin wrote: > Erik, > > On Monday 21 October 2013 11.26.51 Erik Helin wrote: > > Hi all, > > > > this is the second version of a patch for JDK-8025834. > > > > Background: > > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > > "unhandled" oop to the class loader of the Method's class. > > > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > > in the JvmtiBreakpoint that was allocated on the stack. > > > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > > is no need to have a Handle for the _class_loader oop. Once the > > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > > oop will be found via VMThread::oops_do. > > > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > > allocated on the heap, and Handles are only used for oops allocated on > > the stack. > > > > This patch therefore registers the oop as "unhandled" to tell the > > unhandled oop verifier to (rightfully) ignore it. > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > The change looks good to me. > > /Mikael > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8025834 > > > > As I explained in a previous email, there are additional issues in the > > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > > - https://bugs.openjdk.java.net/browse/JDK-8026946 > > - https://bugs.openjdk.java.net/browse/JDK-8026948 > > This change does not intend to fix these issues. > > > > Thanks, > > Erik > From coleen.phillimore at oracle.com Mon Oct 21 07:07:19 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Oct 2013 10:07:19 -0400 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131021084832.GC2608@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> <5260EB79.8080401@oracle.com> <20131018105644.GA2408@ehelin-thinkpad> <20131021084832.GC2608@ehelin-thinkpad> Message-ID: <52653517.5010502@oracle.com> This sounds reasonable. Coleen On 10/21/2013 04:48 AM, Erik Helin wrote: > All, > > after having discussed this issue some more, I've decided to split it into > multiple issues: > - The crash when using -XX:+CheckUnhandledOops > - Using MethodHandle instead of Method* > - Using java_mirror() for anonymous classes > > I will send out a new webrev with a much smaller change that only solves > the first issue (the crash with -XX:+CheckUnhandledOops). This review request > will be labeled (round 2) as in: > RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2). > > For the other two issues, I have created the following two bugs: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > > Everyone, thanks for all your feedback on this change! > Erik > > On 2013-10-18, Erik Helin wrote: >> Hi David and Serguei, >> >> thanks for having a look at this change! >> >> On 2013-10-18, David Holmes wrote: >>> On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>> On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: >>>>> On 10/17/13 11:03 PM, David Holmes wrote: >>>>>> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> The fix looks good in general. >>>>>>> >>>>>>> But one thing is confusing in the fix. >>>>>>> Why do you keep both _class_loader and _class_loader_handle in the >>>>>>> JvmtiBreakpoint class? >>>>>> Even more confusing to me is the fact the neither of these seem to >>>>>> actually be used anywhere ??? >>>>> Nice catch, David. >>>>> I do not see too any of them is really used. >>>>> Is it a leftover after the permgen elimination? >>>> Maybe this is a rush judging. >>>> It depends on the closure->do_oop() that is used for traversing >>>> I thought that the KeepAliveClosure is used below (basing on the comment). >>>> >>>> class JvmtiBreakpoint : public GrowableElement { >>>> . . . >>>> void oops_do(OopClosure* f) { >>>> // Mark the method loader as live >>>> f->do_oop(&_class_loader); >>>> } >>>> >>>> This oops_do() is not needed if we have handle instead of oop. >>> Ah! Maybe the only purpose of keeping the class_loader (whether oop >>> or Handle) is that it is kept alive outside of its normal lifecycle. >>> >>> But still we should only need the Handle or the Oop, not both. And >>> if there is no oop we should not need an oops_do. >> I will try to explain the problem, the current implementation and then >> my change. >> >> The problem >> ----------- >> >> The problem is that JvmtiEnv::SetBreakpoint and >> JvmtiEnv::ClearBreakpoint are passed a Method*. We must ensure that the >> class for this Method is kept alive by the GC. We do this by informing >> the GC that it must visit the class loader for the Method's class when >> marking. This can be done in two ways: >> - Putting a Handle on the stack containing an oop to the class loader >> - Have an oops_do method that we ensure will be called by the GC during >> marking >> >> A third option is to make sure (by inspecting the code) that no GC can >> occur that might cause problems, but this is a very brittle solution >> once a new programmer comes along and adds/removes code. >> >> The current implementation >> -------------------------- >> >> In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a >> JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an >> "unhandled" oop to the class loader of the Method's class. >> >> A pointer to the JvmtiBreakpoint allocated on the stack will be passed >> to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. >> In the doit() method of VM_ChangeBreakpoint, >> JvmtiBreakpoints::set_at_safepoint will be called. A new JvmtiBreakpoint >> will be allocated on the heap by JvmtiBreakpoints::set_at_safepoint. >> >> The JvmtiBreakpoint on the heap will contain the same oop as the one in >> the JvmtiBreakpoint allocated on the stack earlier. The oop in the >> JvmtiBreakpoint allocated on the heap will be found by the GC, because >> VM_ChangeBreakpoint has an oops_do method (see first email for how this >> oops_do method is called). >> >> Once the VM_ChangeBreakpoint operation is done, then the JvmtiBreakpoint >> allocated on the heap will either be cleared due to a clear operation >> (and we do not care about the oop any longer) or it will be placed in >> JvmtiBreakpoints. JvmtiBreakpoints also has an oops_do which ensures >> that the oop now will be found by the GC. >> >> We will now pop the call stack and return to JvmtiEnv::SetBreakpoint or >> JvmtiEnv::ClearBreakpoint. No code in JvmtiEnv::SetBreakpoint or >> JvmtiEnv::ClearBreakpoint is touching the JvmtiBreakpoint after the >> VM_ChangeBreakpoint operation has been run. >> >> Furthermore, no GC can today occur before the call to VMThread::execute >> in JvmtiBreakpoints::set/clear. >> >> This means that the current implementation is safe, but understanding >> this is quite tricky. >> >> The change >> ---------- >> >> My proposed solution was the following: >> - When a JvmtiBreakpoint is allocated on the stack, place an oop to the >> Method's class loader in a Handle. >> - When a JvmtiBreakpoint is allocated on the heap, just store the oop to >> Method's class lodear in a field. The JvmtiBreakpoint will be placed >> in _jvmti_breakpoints which will be visited by the GC, which makes the >> GC call JvmtiBreakpoint::oops_do. >> >> Of course, this means that that if a GC occurs before the >> JvmtiBreakpoint in constructed in JvmtiEnv::SetBreakpoint or >> JvmtiEnv::ClearBreakpoint, the Method's class might be garbage >> collected. Ideally, we should wrap the Method* in jvmti_SetBreakpoint >> and jvmti_ClearBreakpoint in jvmtiEnter.cpp (a cpp file generated from >> an XML file via an XSL tranformation). >> >> As icing on the cake, if someone redefines the method that we are >> receiving a pointer to, then this code will probably not work at all. I >> believe (I am not sure) that this should be solved by having a >> MethodHandle wrapping the Method*. >> >> This change is just a first step towards safer code. >> >> I've gotten feedback internally that it is hard to understand the >> new code. I will try to see if I can update the change to make this >> clearer. >> >> Thanks for getting all the way to the end of this email :) >> >> Erik >> >>> David >>> >>>>>> But if we have the Handle then the oop is redundant AFAICS. >>>>> Right. >>>>> The issue is that the oop version is used in the oops_do. >>>>> Not sure if we can get rid of oops_do. >>>>> It may have an empty body though. >>>> Getting rid of the oops_do will require more cleanup that needs to be >>>> accurate. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> David >>>>>> >>>>>>> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >>>>>>> suites as well. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/17/13 2:28 PM, Erik Helin wrote: >>>>>>>> Hi Mikael and Coleen, >>>>>>>> >>>>>>>> thanks for your reviews! >>>>>>>> >>>>>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>>>>> jvmtiImpl.hpp: >>>>>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>>>>> by the VM operation, would it make sense to >>>>>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>>>>> >>>>>>>>> 196 GrowableElement *clone() { >>>>>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>>>>> _class_loader_handle); >>>>>>>> Agree, I've updated the patch. A new webrev is located at: >>>>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>>>>>>> >>>>>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>>>>> jvmtiEnv.cpp: >>>>>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>>>>> ResourceMark or is it just not needed? >>>>>>>>> - ResourceMark rm; >>>>>>>>> + HandleMark hm; >>>>>>>> The JVMTI entry point does not contain a ResourceMark. However, I have >>>>>>>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>>>>>>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>>>>>>> ResourceMark is JvmtiBreakpoints::prints, but that method already >>>>>>>> has a >>>>>>>> ResourceMark. >>>>>>>> >>>>>>>> On 2013-10-16, Coleen Phillimore wrote: >>>>>>>>> Did you run the nsk.jvmti.testlist tests too though? >>>>>>>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>>>>>>> >>>>>>>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>>>>>>> also run with and without -XX:+CheckUnhandledOops. The results were >>>>>>>> all >>>>>>>> the same: 598 passed an 11 failed (the same tests for all >>>>>>>> combinations). >>>>>>>> So, the patch does not introduce any regressions for this test suite. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>>> >>>>>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>>>>> Erik, >>>>>>>>> >>>>>>>>> (it's not necessary to cross-post between hotspot-dev and >>>>>>>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>>>>>>> >>>>>>>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>>>>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>>>>>>> detector. >>>>>>>>>> >>>>>>>>>> Instead of registering the oop as an unhandled oop, which would have >>>>>>>>>> worked, I decided to wrap the oop in a handle as long as it is on >>>>>>>>>> the >>>>>>>>>> stack. >>>>>>>>>> >>>>>>>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>>>>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>>>>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>>>>>>> and oop >>>>>>>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>>>>>>> when >>>>>>>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native >>>>>>>>>> heap, copy >>>>>>>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>>>>>>> place/clear the >>>>>>>>>> newly alloacted JvmtiBreakpoint in >>>>>>>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>>>>>>> >>>>>>>>>> I have updated to the code to check that the public constructor >>>>>>>>>> is only >>>>>>>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>>>>>>> programmer if he/she decides to allocate one on the heap). The >>>>>>>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>>>>>>> JvmtiBreakpoints. >>>>>>>>>> >>>>>>>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>>>>>>> handle, >>>>>>>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>>>>>>> makes the oop in the handle safe for use after the >>>>>>>>>> VM_ChangeBreakpoint >>>>>>>>>> operation is finished. >>>>>>>>>> >>>>>>>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>>>>>>> will be >>>>>>>>>> visited by the GC via jvmtiExport::oops_do -> >>>>>>>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>>>>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is >>>>>>>>>> being >>>>>>>>>> added to. >>>>>>>>>> >>>>>>>>>> I've also removed some dead code to simplify the change: >>>>>>>>>> - GrowableCache::insert >>>>>>>>>> - JvmtiBreakpoint::copy >>>>>>>>>> - JvmtiBreakpoint::lessThan >>>>>>>>>> - GrowableElement::lessThan >>>>>>>>>> >>>>>>>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>>>>>>> Jvmti::SetBreakpoint exactly the same to highlight that they >>>>>>>>>> share all >>>>>>>>>> code except one line. Unfortunately, I was not able to remove >>>>>>>>>> this code >>>>>>>>>> duplication in a good way. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>>>>>>> jvmtiImpl.hpp: >>>>>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>>>>> by the VM operation, would it make sense to >>>>>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>>>>> >>>>>>>>> 196 GrowableElement *clone() { >>>>>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>>>>> _class_loader_handle); >>>>>>>>> >>>>>>>>> jvmtiImpl.cpp: >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> jvmtiEnv.cpp: >>>>>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>>>>> ResourceMark or is it just not needed? >>>>>>>>> - ResourceMark rm; >>>>>>>>> + HandleMark hm; >>>>>>>>> >>>>>>>>> Otherwise the code change looks good. >>>>>>>>> >>>>>>>>> >>>>>>>>> One thing that you didn't describe here, but which was related to >>>>>>>>> the bug (which we discussed) was the fact that the old code tried to >>>>>>>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>>>>>>> added a Method*: >>>>>>>>> >>>>>>>>> thread->allow_unhandled_oop((oop*)&_method); >>>>>>>>> >>>>>>>>> We should take care to find other such places where we try to put a >>>>>>>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>>>>>>> the unhandled oops code. >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> - JPRT >>>>>>>>>> - The four tests that were failing are now passing >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Erik >>>>>>>>>> From coleen.phillimore at oracle.com Mon Oct 21 07:08:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Oct 2013 10:08:17 -0400 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <52653551.9010802@oracle.com> Erik, This looks good. Thanks, Coleen On 10/21/2013 05:26 AM, Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik From daniel.daugherty at oracle.com Mon Oct 21 08:20:24 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 21 Oct 2013 09:20:24 -0600 Subject: Solaris fastdebug build: gobjcopy? In-Reply-To: <52651DDF.9050000@oracle.com> References: <5264ED10.7000308@oracle.com> <5265122A.30101@oracle.com> <52651DDF.9050000@oracle.com> Message-ID: <52654638.4000500@oracle.com> Running configure on a machine with gobjcopy and then running the build on a machine without gobjcopy would explain the failure mode that you're seeing. You need to file a bug with the build-infra folks. The old build system wouldn't have had this problem because there was no configure step. I'm not completely up to speed on the new build-infra stuff so pinging them is your best bet. Dan On 10/21/13 6:28 AM, Weijun Wang wrote: > This is a full build, but I run configure on one machine and make from > another. Doing both on the same machine without gobjcopy runs fine. > > Thanks > Max > > On 10/21/13 7:38 PM, David Holmes wrote: >> If gobjcopy is >> installed somewhere then ALT_OBJCOPY can be set to point to it. Was this >> part of a full build? The configure process might also find gobjcopy and >> set the appropriate variables. >> >> David >> >>> Thanks >>> Max From david.dehaven at oracle.com Mon Oct 21 08:58:36 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 08:58:36 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <526570DB.9070509@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> Message-ID: <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Thanks guys. Anthony, can you sponsor this for me? -DrD- > This fix looks fine to me as well. > > -- > best regards, > Anthony > > On 10/20/2013 11:56 PM, David DeHaven wrote: >> >> CCing: build-dev, macosx-port-dev, hotspot-dev >> >> Request for review of JDK-8025673: >> https://bugs.openjdk.java.net/browse/JDK-8025673 >> >> Proposed changes: >> http://cr.openjdk.java.net/~ddehaven/8025673/ >> >> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >> >> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >> >> Significant build system changes, build-dev guys are encouraged to comment... >> >> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >> >> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >> >> >> Question for the AWT team, we still have this in java_props_md.c: >> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >> 459 if (prefToolkit == CToolkit) { >> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >> 461 } else { >> 462 // TODO: do we still need this? >> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >> 464 } >> >> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >> >> >> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >> >> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >> >> -DrD- >> From karen.kinnear at oracle.com Wed Oct 16 21:17:18 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Oct 2013 00:17:18 -0400 Subject: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> Message-ID: <8A950C68-FA54-4744-9620-D6ADF87996D6@oracle.com> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: > Please review quickly: > > webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026365 > > Verifier called is_reference_assignable, which called resolve_or_null, which was looking for > the anonymous class in the system dictionary, where it is not. So this will allow more anonymous > class cases to get through the verifier while still doing validity checking (but on the host class only, > not on the anonymous class). > > Tested: > Robert's new test: reduct (which he will check in as part of the lambda side of this change) > Lam > Lam1 > > in progress: vm.quick, java.lang, java.util, Nashorn > > thanks, > Karen > > p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? > > p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he > had given me > From daniel.daugherty at oracle.com Thu Oct 17 06:09:15 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Oct 2013 07:09:15 -0600 Subject: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <8A950C68-FA54-4744-9620-D6ADF87996D6@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <8A950C68-FA54-4744-9620-D6ADF87996D6@oracle.com> Message-ID: <525FE17B.4060302@oracle.com> > webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ src/share/vm/classfile/verifier.cpp Just to verify that I understand this tweak: new lines 2442-2444 - check for anonymous class first before deciding which ref_class_type.is_assignable_from() form to use. old code: made a ref_class_type.is_assignable_from() call and then checked for anonymous class before doing another ref_class_type.is_assignable_from() call The above looks right. old code: current_type().is_assignable_from() call made, if that didn't work, then checked hosttype.is_assignable_from() new code: recognize that current_type() is an anonymous class and call hosttype.is_assignable_from() straight away The above also looks right. As for logistics of getting this fix to T&L quickly: if this fix doesn't depend on other fixes that we just pushed from RT_Baseline -> Main_Baseline yesterday, then you should consider pushing this fix to T&L's hotspot repo. Of course, I'm presuming that the T&L folks are doing builds that include hotspot rather than relying on the import JDK hotspot. if this fix does depend on other fixes that we just pushed from RT_Baseline -> Main_Baseline yesterday, then you need to hear from Alejandro and/or John C about whether a direct Main_Baseline push will be permitted. If this fix does not go to T&L directly, then they won't get the fix until after Tuesday of next week. The next HSX-25 snapshot will push to JDK8 on Tuesday if it passes PIT. And then T&L would have to sync-down from JDK8 after that. Dan On 10/16/13 10:17 PM, Karen Kinnear wrote: > On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: > >> Please review quickly: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >> >> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >> class cases to get through the verifier while still doing validity checking (but on the host class only, >> not on the anonymous class). >> >> Tested: >> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >> Lam >> Lam1 >> >> in progress: vm.quick, java.lang, java.util, Nashorn >> >> thanks, >> Karen >> >> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >> >> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >> had given me >> From karen.kinnear at oracle.com Thu Oct 17 06:26:34 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Oct 2013 09:26:34 -0400 Subject: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <525FE17B.4060302@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <8A950C68-FA54-4744-9620-D6ADF87996D6@oracle.com> <525FE17B.4060302@oracle.com> Message-ID: <24E75EF7-C3E2-4B8A-95F1-E6C643493E6E@oracle.com> Thank you Dan for the rapid code review, and yes you understood the change. Vincente is running additional tests with Robert's upcoming changes. Given we did a special push of 8026022 last week to master and it is not yet in tl, I think it does make sense to get this into TL directly - if that works for Vincente and Lana. There will be an extra challenge - when 8026022/8026547 (backport id I think) gets to tl and master we will need to make sure that 8026365 overwrites that - i.e. a manual merge of hotspot/src/share/vm/classfile/verifier.cpp so we don't go backwards. thank you so much, Karen On Oct 17, 2013, at 9:09 AM, Daniel D. Daugherty wrote: > > webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ > > src/share/vm/classfile/verifier.cpp > Just to verify that I understand this tweak: > > new lines 2442-2444 - check for anonymous class first before > deciding which ref_class_type.is_assignable_from() form > to use. > > old code: made a ref_class_type.is_assignable_from() call and > then checked for anonymous class before doing another > ref_class_type.is_assignable_from() call > > The above looks right. > > old code: current_type().is_assignable_from() call made, if > that didn't work, then checked hosttype.is_assignable_from() > > new code: recognize that current_type() is an anonymous class > and call hosttype.is_assignable_from() straight away > > The above also looks right. > > As for logistics of getting this fix to T&L quickly: > > if this fix doesn't depend on other fixes that we just pushed > from RT_Baseline -> Main_Baseline yesterday, then you should > consider pushing this fix to T&L's hotspot repo. Of course, I'm > presuming that the T&L folks are doing builds that include > hotspot rather than relying on the import JDK hotspot. > > if this fix does depend on other fixes that we just pushed > from RT_Baseline -> Main_Baseline yesterday, then you need to > hear from Alejandro and/or John C about whether a direct > Main_Baseline push will be permitted. > > If this fix does not go to T&L directly, then they won't get the > fix until after Tuesday of next week. The next HSX-25 snapshot will > push to JDK8 on Tuesday if it passes PIT. And then T&L would have > to sync-down from JDK8 after that. > > Dan > > > On 10/16/13 10:17 PM, Karen Kinnear wrote: >> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >> >>> Please review quickly: >>> >>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>> >>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>> not on the anonymous class). >>> >>> Tested: >>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>> Lam >>> Lam1 >>> >>> in progress: vm.quick, java.lang, java.util, Nashorn >>> >>> thanks, >>> Karen >>> >>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>> >>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>> had given me >>> > From daniel.daugherty at oracle.com Thu Oct 17 07:06:02 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Oct 2013 08:06:02 -0600 Subject: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <24E75EF7-C3E2-4B8A-95F1-E6C643493E6E@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <8A950C68-FA54-4744-9620-D6ADF87996D6@oracle.com> <525FE17B.4060302@oracle.com> <24E75EF7-C3E2-4B8A-95F1-E6C643493E6E@oracle.com> Message-ID: <525FEECA.1020707@oracle.com> On 10/17/13 7:26 AM, Karen Kinnear wrote: > Thank you Dan for the rapid code review, and yes you understood the change. > > Vincente is running additional tests with Robert's upcoming changes. > > Given we did a special push of 8026022 last week to master and it is not yet in tl, > I think it does make sense to get this into TL directly - if that works for Vincente and Lana. I don't see any special hoops for 8026022. It looks like it went to Main_Baseline on 2013-10-10, went to the HSX-25 snapshot on 2013-10-11 and went to JDK8 on 2013-10-15. All appear to normal pushes. I do remember a different fix a few builds ago requiring a special push, but it appears that 8026022 was "normal". I didn't remember to check the current state of jdk8/tl/hotspot. That repo is currently at tag jdk8-b111/hs25-b53 so it does not have _any_ of the hs25-b54 code that just went through PIT. Just to make life interesting, T&L is having some issues with javac assertions and build problems in corba which prevented yesterday's regularly scheduled snapshot from being taken. Last e-mail I saw from Lana said she was holding her JDK8-B113 snapshot until today. Lana's normal process would sync-down from JDK8 -> T&L after today's promotion so that will get T&L caught up with jdk8-b112/hs25-b54. > There will be an extra challenge - when 8026022/8026547 (backport id I think) gets > to tl and master we will need to make sure that 8026365 overwrites that - i.e. a manual > merge of hotspot/src/share/vm/classfile/verifier.cpp so we don't go backwards. My recommendation would be to commit your fix for 8026365 relative to an hsx-25-b54 repo, wait for T&L to get resync'ed with JDK8 and then push your fix to T&L/hotspot. Of course, this still presumes that the folks that need this fix are doing forest builds that include the hotspot repo... I can get the special repo setup shortly. Dan > > thank you so much, > Karen > > On Oct 17, 2013, at 9:09 AM, Daniel D. Daugherty wrote: > >>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >> src/share/vm/classfile/verifier.cpp >> Just to verify that I understand this tweak: >> >> new lines 2442-2444 - check for anonymous class first before >> deciding which ref_class_type.is_assignable_from() form >> to use. >> >> old code: made a ref_class_type.is_assignable_from() call and >> then checked for anonymous class before doing another >> ref_class_type.is_assignable_from() call >> >> The above looks right. >> >> old code: current_type().is_assignable_from() call made, if >> that didn't work, then checked hosttype.is_assignable_from() >> >> new code: recognize that current_type() is an anonymous class >> and call hosttype.is_assignable_from() straight away >> >> The above also looks right. >> >> As for logistics of getting this fix to T&L quickly: >> >> if this fix doesn't depend on other fixes that we just pushed >> from RT_Baseline -> Main_Baseline yesterday, then you should >> consider pushing this fix to T&L's hotspot repo. Of course, I'm >> presuming that the T&L folks are doing builds that include >> hotspot rather than relying on the import JDK hotspot. >> >> if this fix does depend on other fixes that we just pushed >> from RT_Baseline -> Main_Baseline yesterday, then you need to >> hear from Alejandro and/or John C about whether a direct >> Main_Baseline push will be permitted. >> >> If this fix does not go to T&L directly, then they won't get the >> fix until after Tuesday of next week. The next HSX-25 snapshot will >> push to JDK8 on Tuesday if it passes PIT. And then T&L would have >> to sync-down from JDK8 after that. >> >> Dan >> >> >> On 10/16/13 10:17 PM, Karen Kinnear wrote: >>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>> >>>> Please review quickly: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>> >>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>> not on the anonymous class). >>>> >>>> Tested: >>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>> Lam >>>> Lam1 >>>> >>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>> >>>> thanks, >>>> Karen >>>> >>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>> >>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>> had given me >>>> > > > From lana.steuck at oracle.com Thu Oct 17 07:58:27 2013 From: lana.steuck at oracle.com (Lana Steuck) Date: Thu, 17 Oct 2013 07:58:27 -0700 Subject: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <24E75EF7-C3E2-4B8A-95F1-E6C643493E6E@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <8A950C68-FA54-4744-9620-D6ADF87996D6@oracle.com> <525FE17B.4060302@oracle.com> <24E75EF7-C3E2-4B8A-95F1-E6C643493E6E@oracle.com> Message-ID: <525FFB13.2070807@oracle.com> On 10/17/2013 06:26 AM, Karen Kinnear wrote: > Thank you Dan for the rapid code review, and yes you understood the change. > > Vincente is running additional tests with Robert's upcoming changes. > > Given we did a special push of 8026022 last week to master and it is not yet in tl, > I think it does make sense to get this into TL directly - if that works for Vincente and Lana. I am fine with a hotspot fix going into TL (and I always do full build), however this is not up to me, TL guys should OK this (cc-ing tl-dev_ww_grp). Another question is - how this fix would go through hotspot SQE if you push it to TL forest? > > There will be an extra challenge - when 8026022/8026547 (backport id I think) gets > to tl and master we will need to make sure that 8026365 overwrites that - i.e. a manual > merge of hotspot/src/share/vm/classfile/verifier.cpp so we don't go backwards. > > thank you so much, > Karen > > On Oct 17, 2013, at 9:09 AM, Daniel D. Daugherty wrote: > >>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >> src/share/vm/classfile/verifier.cpp >> Just to verify that I understand this tweak: >> >> new lines 2442-2444 - check for anonymous class first before >> deciding which ref_class_type.is_assignable_from() form >> to use. >> >> old code: made a ref_class_type.is_assignable_from() call and >> then checked for anonymous class before doing another >> ref_class_type.is_assignable_from() call >> >> The above looks right. >> >> old code: current_type().is_assignable_from() call made, if >> that didn't work, then checked hosttype.is_assignable_from() >> >> new code: recognize that current_type() is an anonymous class >> and call hosttype.is_assignable_from() straight away >> >> The above also looks right. >> >> As for logistics of getting this fix to T&L quickly: >> >> if this fix doesn't depend on other fixes that we just pushed >> from RT_Baseline -> Main_Baseline yesterday, then you should >> consider pushing this fix to T&L's hotspot repo. Of course, I'm >> presuming that the T&L folks are doing builds that include >> hotspot rather than relying on the import JDK hotspot. >> >> if this fix does depend on other fixes that we just pushed >> from RT_Baseline -> Main_Baseline yesterday, then you need to >> hear from Alejandro and/or John C about whether a direct >> Main_Baseline push will be permitted. >> >> If this fix does not go to T&L directly, then they won't get the >> fix until after Tuesday of next week. The next HSX-25 snapshot will >> push to JDK8 on Tuesday if it passes PIT. And then T&L would have >> to sync-down from JDK8 after that. >> >> Dan >> >> >> On 10/16/13 10:17 PM, Karen Kinnear wrote: >>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>> >>>> Please review quickly: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>> >>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>> not on the anonymous class). >>>> >>>> Tested: >>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>> Lam >>>> Lam1 >>>> >>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>> >>>> thanks, >>>> Karen >>>> >>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>> >>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>> had given me >>>> From lana.steuck at oracle.com Thu Oct 17 23:05:55 2013 From: lana.steuck at oracle.com (Lana Steuck) Date: Thu, 17 Oct 2013 23:05:55 -0700 Subject: Test webrev review please: Re: RFR ASAP please: 8026365: Fix verifier for anonymous classes In-Reply-To: <7B37E46C-1968-43ED-A6F0-DC0E1F9B645F@oracle.com> References: <8F18DF72-3B94-489E-B2DC-A699F6CFD4DB@oracle.com> <4F2974DF-5B34-4386-88CC-1113BDB2F642@oracle.com> <52603D7B.4050401@oracle.com> <062BDA16-B9E9-43E2-B987-765EC5F9186A@oracle.com> <5260A5CB.2070504@oracle.com> <7B37E46C-1968-43ED-A6F0-DC0E1F9B645F@oracle.com> Message-ID: <5260CFC3.2050700@oracle.com> fyi: TL is now synced up with jdk8 Master. - Lana On 10/17/2013 08:16 PM, Karen Kinnear wrote: > David, > > InvokeSpecialAnonTest.java needs the jdk to provide objectweb.asm to build, in fact it needed a special flag to > find it. But let me know if that is in one of the smaller profiles - I don't know where to look that up. > > I will retry the missing test directory and get back to you on that. Sounds like I was mistaken (?) > > thanks, > Karen > > On Oct 17, 2013, at 11:06 PM, David Holmes wrote: > >> On 18/10/2013 6:41 AM, Karen Kinnear wrote: >>> No - I attached the file directly. I couldn't figure out how to get webrev to show a new file without >>> doing a commit. So I didn't use the webrev for review - but thanks for looking at it - because I >>> forgot to send the TEST.groups. If I understand correctly, we now need to add to that whenever adding >>> a test that needs the full jdk as this one does for the asm library. >>> >>> That said - I had to change test/TEST.groups in order to run my test - because the test itself >>> doesn't exist and the new mechanism to split things based on profiles seems intolerant - i.e. it doesn't >>> just report a problem and continue - it stops dead in its tracks. I'm sure David H will be delighted to fix that. >> Not sure what you mean. If a group lists a test that doesn't exist then jtreg will report that while parsing the groups file but otherwise it is ignored. >> >> BTW I don't see why InvokeSpecialAnonTest.java is listed as needs_jdk ?? >> >> David >> ----- >> >>> On Oct 17, 2013, at 3:41 PM, Daniel D. Daugherty wrote: >>> >>>> I'm guessing that you mean this webrev: >>>> >>>>> http://cr.openjdk.java.net/~acorn/8026365.test/webrev/ >>>> src/share/vm/classfile/verifier.cpp >>>> This webrev is against the current T&L/hotspot version instead >>>> of the version that is being sync'ed down from JDK8. >>>> >>>> test/TEST.groups >>>> runtime/8026365/InvokeSpecialAnonTest.java is added to this list >>>> but is not included in the webrev. >>>> >>>> Why is runtime/6878713/Test6878713.sh deleted in this webrev? >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> On 10/17/13 12:17 PM, Karen Kinnear wrote: >>>>> Added test (thanks to Robert Field). Please review: >>>>> >>>>> >>>>> >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Oct 17, 2013, at 12:13 AM, Karen Kinnear wrote: >>>>> >>>>>> Please review quickly: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~acorn/8026365/webrev/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026365 >>>>>> >>>>>> Verifier called is_reference_assignable, which called resolve_or_null, which was looking for >>>>>> the anonymous class in the system dictionary, where it is not. So this will allow more anonymous >>>>>> class cases to get through the verifier while still doing validity checking (but on the host class only, >>>>>> not on the anonymous class). >>>>>> >>>>>> Tested: >>>>>> Robert's new test: reduct (which he will check in as part of the lambda side of this change) >>>>>> Lam >>>>>> Lam1 >>>>>> >>>>>> in progress: vm.quick, java.lang, java.util, Nashorn >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> p.s. Alejandro, Dan, Calvin - they want this in TL ASAP - should I check this directly into hotspot-master tomorrow? >>>>>> >>>>>> p.s. Vincente - can you grab this patch to test with Robert's changes please? I tested with the patches he >>>>>> had given me >>>>>> From magnus.ihse.bursie at oracle.com Mon Oct 21 05:21:34 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2013 14:21:34 +0200 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5264E663.7050401@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <5264E663.7050401@oracle.com> Message-ID: <23EDEC19-5FF1-4D80-A196-58C915AD0484@oracle.com> I agree with Erik once more. /Magnus 21 okt 2013 kl. 10:31 skrev Erik Joelsson : > Hello David, > > From a build point of view, the changes look fine to me. > > /Erik > > On 2013-10-21 01:56, David DeHaven wrote: >> CCing: build-dev, macosx-port-dev, hotspot-dev >> >> Request for review of JDK-8025673: >> https://bugs.openjdk.java.net/browse/JDK-8025673 >> >> Proposed changes: >> http://cr.openjdk.java.net/~ddehaven/8025673/ >> >> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >> >> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >> >> Significant build system changes, build-dev guys are encouraged to comment... >> >> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >> >> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >> >> >> Question for the AWT team, we still have this in java_props_md.c: >> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >> 459 if (prefToolkit == CToolkit) { >> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >> 461 } else { >> 462 // TODO: do we still need this? >> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >> 464 } >> >> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >> >> >> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >> >> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >> >> -DrD- > From magnus.ihse.bursie at oracle.com Mon Oct 21 06:18:42 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2013 15:18:42 +0200 Subject: Solaris fastdebug build: gobjcopy? In-Reply-To: <52651DDF.9050000@oracle.com> References: <5264ED10.7000308@oracle.com> <5265122A.30101@oracle.com> <52651DDF.9050000@oracle.com> Message-ID: 21 okt 2013 kl. 14:28 skrev Weijun Wang : > This is a full build, but I run configure on one machine and make from another. That is not a supported use case. Configure checks the local machine and prepares the build. /Magnus > Doing both on the same machine without gobjcopy runs fine. > > Thanks > Max > > On 10/21/13 7:38 PM, David Holmes wrote: >> If gobjcopy is >> installed somewhere then ALT_OBJCOPY can be set to point to it. Was this >> part of a full build? The configure process might also find gobjcopy and >> set the appropriate variables. >> >> David >> >>> Thanks >>> Max From anthony.petrov at oracle.com Mon Oct 21 11:22:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Oct 2013 18:22:19 +0000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <526570DB.9070509@oracle.com> This fix looks fine to me as well. -- best regards, Anthony On 10/20/2013 11:56 PM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. > > > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From yekaterina.kantserova at oracle.com Mon Oct 21 08:23:41 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 21 Oct 2013 17:23:41 +0200 Subject: Fwd: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525D4490.3070506@oracle.com> References: <525D4490.3070506@oracle.com> Message-ID: <526546FD.5020909@oracle.com> Hi, I've done following changes after the reviews: - added open copyrights - documented all public functions in jdk.testlibrary.TestThread, jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils - merged jdk.testlibrary.Asserts from hotspot testlibrary Jaroslav's comments: - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, different exception can show up there while waiting until jstatd is up and running; better just look for valid pid; - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since jstatd process is daemon, the "clean up" is to kill the target process. Please look at the changed JstatdHelper and tell me if it's still unclear. - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() should be called in "finally" - fixed Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 Thanks, Katja From david.dehaven at oracle.com Mon Oct 21 12:54:17 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 12:54:17 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. -DrD- > Thanks guys. > > Anthony, can you sponsor this for me? > > -DrD- > >> This fix looks fine to me as well. >> >> -- >> best regards, >> Anthony >> >> On 10/20/2013 11:56 PM, David DeHaven wrote: >>> >>> CCing: build-dev, macosx-port-dev, hotspot-dev >>> >>> Request for review of JDK-8025673: >>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>> >>> Proposed changes: >>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>> >>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>> >>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>> >>> Significant build system changes, build-dev guys are encouraged to comment... >>> >>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>> >>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>> >>> >>> Question for the AWT team, we still have this in java_props_md.c: >>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>> 459 if (prefToolkit == CToolkit) { >>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>> 461 } else { >>> 462 // TODO: do we still need this? >>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>> 464 } >>> >>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>> >>> >>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>> >>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>> >>> -DrD- >>> > From serguei.spitsyn at oracle.com Mon Oct 21 14:02:19 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 21 Oct 2013 14:02:19 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <5265965B.3090406@oracle.com> Erik, It looks good. Thank you for filing new bugs. Thanks, Serguei On 10/21/13 2:26 AM, Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik From david.holmes at oracle.com Mon Oct 21 16:09:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2013 09:09:57 +1000 Subject: XXS: RFR 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles In-Reply-To: References: <5264CCF2.6070001@oracle.com> Message-ID: <5265B445.8060901@oracle.com> Thanks Staffan! Can I get a second reviewer please! This is very simple. Thanks, David On 21/10/2013 7:03 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 21 okt 2013, at 08:42, David Holmes wrote: > >> The precompiled classes used by these tests are defined to extend java.applet.Applet and so require a full JRE for execution. These tests (which were recently renamed and converted to Java from a sh script) need to be added to the :needs_jre group in TEST.groups. >> >> Testing for this issue also found another missing group entry: >> >> gc/metaspace/TestPerfCountersAndMemoryPools.java - needs_jdk >> >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8026872/webrev/ >> >> Thanks, >> David > From weijun.wang at oracle.com Mon Oct 21 16:31:26 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Oct 2013 07:31:26 +0800 Subject: Solaris fastdebug build: gobjcopy? In-Reply-To: References: <5264ED10.7000308@oracle.com> <5265122A.30101@oracle.com> <52651DDF.9050000@oracle.com> Message-ID: <5265B94E.8000807@oracle.com> On 10/21/13 9:18 PM, Magnus Ihse Bursie wrote: > 21 okt 2013 kl. 14:28 skrev Weijun Wang : > >> This is a full build, but I run configure on one machine and make from another. > > That is not a supported use case. Configure checks the local machine and prepares the build. Yes I know. On the other hand, since the build process is able to workaround with the missing tool at the earlier stages it should be able to do that later. If you think it's worth an enhancement I'll file a bug. Thanks Max > > /Magnus > > >> Doing both on the same machine without gobjcopy runs fine. >> >> Thanks >> Max >> >> On 10/21/13 7:38 PM, David Holmes wrote: >>> If gobjcopy is >>> installed somewhere then ALT_OBJCOPY can be set to point to it. Was this >>> part of a full build? The configure process might also find gobjcopy and >>> set the appropriate variables. >>> >>> David >>> >>>> Thanks >>>> Max From alejandro.murillo at oracle.com Mon Oct 21 17:22:00 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 22 Oct 2013 00:22:00 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8023496: [jprt] build and test solaris 64-bits only Message-ID: <20131022002202.F2C34625D2@hg.openjdk.java.net> Changeset: 384c92148c68 Author: amurillo Date: 2013-10-21 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/384c92148c68 8023496: [jprt] build and test solaris 64-bits only Reviewed-by: tbell, jcoomes ! make/jprt.properties From david.holmes at oracle.com Mon Oct 21 17:22:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2013 10:22:53 +1000 Subject: Solaris fastdebug build: gobjcopy? In-Reply-To: <5265B94E.8000807@oracle.com> References: <5264ED10.7000308@oracle.com> <5265122A.30101@oracle.com> <52651DDF.9050000@oracle.com> <5265B94E.8000807@oracle.com> Message-ID: <5265C55D.3010508@oracle.com> On 22/10/2013 9:31 AM, Weijun Wang wrote: > On 10/21/13 9:18 PM, Magnus Ihse Bursie wrote: >> 21 okt 2013 kl. 14:28 skrev Weijun Wang : >> >>> This is a full build, but I run configure on one machine and make >>> from another. >> >> That is not a supported use case. Configure checks the local machine >> and prepares the build. > > Yes I know. > > On the other hand, since the build process is able to workaround with > the missing tool at the earlier stages it should be able to do that later. The whole point of the configure step is to identify all the build tools and dependencies etc and resolve them. It makes no sense to run configure on one machine and make on another. That aside I still think there may be a bug in the hotspot makefiles. David > If you think it's worth an enhancement I'll file a bug. > > Thanks > Max > >> >> /Magnus >> >> >>> Doing both on the same machine without gobjcopy runs fine. >>> >>> Thanks >>> Max >>> >>> On 10/21/13 7:38 PM, David Holmes wrote: >>>> If gobjcopy is >>>> installed somewhere then ALT_OBJCOPY can be set to point to it. Was >>>> this >>>> part of a full build? The configure process might also find gobjcopy >>>> and >>>> set the appropriate variables. >>>> >>>> David >>>> >>>>> Thanks >>>>> Max From serguei.spitsyn at oracle.com Mon Oct 21 17:36:12 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 21 Oct 2013 17:36:12 -0700 Subject: XXS: RFR 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles In-Reply-To: <5265B445.8060901@oracle.com> References: <5264CCF2.6070001@oracle.com> <5265B445.8060901@oracle.com> Message-ID: <5265C87C.7000007@oracle.com> Looks good. Thanks, Serguei On 10/21/13 4:09 PM, David Holmes wrote: > Thanks Staffan! > > Can I get a second reviewer please! This is very simple. > > Thanks, > David > > On 21/10/2013 7:03 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >> On 21 okt 2013, at 08:42, David Holmes wrote: >> >>> The precompiled classes used by these tests are defined to extend >>> java.applet.Applet and so require a full JRE for execution. These >>> tests (which were recently renamed and converted to Java from a sh >>> script) need to be added to the :needs_jre group in TEST.groups. >>> >>> Testing for this issue also found another missing group entry: >>> >>> gc/metaspace/TestPerfCountersAndMemoryPools.java - needs_jdk >>> >>> webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8026872/webrev/ >>> >>> Thanks, >>> David >> From david.dehaven at oracle.com Mon Oct 21 20:34:30 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 20:34:30 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: Updated webrev for JDK (hotspot change is the same): http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ Changes since last version: - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] -DrD- > I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. > > -DrD- > >> Thanks guys. >> >> Anthony, can you sponsor this for me? >> >> -DrD- >> >>> This fix looks fine to me as well. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>> >>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>> >>>> Request for review of JDK-8025673: >>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>> >>>> Proposed changes: >>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>> >>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>> >>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>> >>>> Significant build system changes, build-dev guys are encouraged to comment... >>>> >>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>> >>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>> >>>> >>>> Question for the AWT team, we still have this in java_props_md.c: >>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>> 459 if (prefToolkit == CToolkit) { >>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>> 461 } else { >>>> 462 // TODO: do we still need this? >>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>> 464 } >>>> >>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>> >>>> >>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>> >>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>> >>>> -DrD- >>>> >> > From erik.joelsson at oracle.com Tue Oct 22 02:13:00 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2013 11:13:00 +0200 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: <5266419C.5090705@oracle.com> Still looks good to me. /Erik On 2013-10-22 05:34, David DeHaven wrote: > Updated webrev for JDK (hotspot change is the same): > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ > > Changes since last version: > - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk > - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] > > -DrD- > > >> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >> >> -DrD- >> >>> Thanks guys. >>> >>> Anthony, can you sponsor this for me? >>> >>> -DrD- >>> >>>> This fix looks fine to me as well. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>> >>>>> Request for review of JDK-8025673: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>> >>>>> Proposed changes: >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>> >>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>> >>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>> >>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>> >>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>> >>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>> >>>>> >>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>> 459 if (prefToolkit == CToolkit) { >>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>> 461 } else { >>>>> 462 // TODO: do we still need this? >>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>> 464 } >>>>> >>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>> >>>>> >>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>> >>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>> >>>>> -DrD- >>>>> From artem.ananiev at oracle.com Tue Oct 22 02:23:49 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 22 Oct 2013 13:23:49 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: <52664425.4080201@oracle.com> Hi, David, thanks for additional cleanup. I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? Thanks, Artem On 10/22/2013 7:34 AM, David DeHaven wrote: > > Updated webrev for JDK (hotspot change is the same): > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ > > Changes since last version: > - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk > - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] > > -DrD- > > >> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >> >> -DrD- >> >>> Thanks guys. >>> >>> Anthony, can you sponsor this for me? >>> >>> -DrD- >>> >>>> This fix looks fine to me as well. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>> >>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>> >>>>> Request for review of JDK-8025673: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>> >>>>> Proposed changes: >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>> >>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>> >>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>> >>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>> >>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>> >>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>> >>>>> >>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>> 459 if (prefToolkit == CToolkit) { >>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>> 461 } else { >>>>> 462 // TODO: do we still need this? >>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>> 464 } >>>>> >>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>> >>>>> >>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>> >>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>> >>>>> -DrD- >>>>> >>> >> > From david.dehaven at oracle.com Tue Oct 22 09:09:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 09:09:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52665067.40102@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <52665067.40102@oracle.com> Message-ID: <9CE00A53-DEAC-4BEB-8965-6EA420451B68@oracle.com> Oops, you're right, it definitely crashes. I'll put that code back and take Artem's suggestion. -DrD- > Artem is correct. On Mac we can't start a GUI session via ssh, for example. Thus we choose the headless mode then. The isInAquaSession() is supposed to perform exactly this check. This logic needs to be preserved. > > -- > best regards, > Anthony > > On 10/22/2013 01:23 PM, Artem Ananiev wrote: >> Hi, David, >> >> thanks for additional cleanup. >> >> I have only one concern. Before the fix, we checked if there is an >> active Aqua session. When no session was found, we falled back to >> HToolkit. I think this logic should be preserved, but slightly >> corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >> >> Otherwise the only way to run headless on Mac will be to force it with >> the system property. It works this way on Windows, but on Windows we're >> sure that WToolkit can run even without a UI session. Is it also true on >> Mac? Did you try to launch AWT without -Djava.awt.headless=true from >> remote console with no users logged in? >> >> Thanks, >> >> Artem >> >> On 10/22/2013 7:34 AM, David DeHaven wrote: >>> >>> Updated webrev for JDK (hotspot change is the same): >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>> >>> Changes since last version: >>> - Moved to jdk8/build/jdk to save someone a merge headache, moved >>> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>> - Removed HToolkit option and toolkit selection code from >>> java_props_macosx.[ch] >>> >>> -DrD- >>> >>> >>>> I want to do one more iteration of this. Based on feedback it seems I >>>> can remove a bit more code from java_props_macosx.[ch] and make >>>> things a bit cleaner. >>>> >>>> -DrD- >>>> >>>>> Thanks guys. >>>>> >>>>> Anthony, can you sponsor this for me? >>>>> >>>>> -DrD- >>>>> >>>>>> This fix looks fine to me as well. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>> >>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>> >>>>>>> Request for review of JDK-8025673: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>> >>>>>>> Proposed changes: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>> >>>>>>> This change disables building libawt_xawt.dylib and >>>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>>> supported. There are too many challenges (and not enough time) in >>>>>>> removing all X11 code from the Mac build at this time, so we're >>>>>>> deferring complete removal for later (will be covered by >>>>>>> JDK-8003900). >>>>>>> >>>>>>> A small change to hotspot is required as it was looking for >>>>>>> libawt_xawt.dylib and if not found would set java.awt.headless to >>>>>>> true. Since we don't build a headless only JRE on Mac I just have >>>>>>> that method return false. I'm not sure how to handle changes to >>>>>>> hotspot, can it be pushed along with the jdk changes? Without that >>>>>>> change the Mac builds will be broken. >>>>>>> >>>>>>> Significant build system changes, build-dev guys are encouraged to >>>>>>> comment... >>>>>>> >>>>>>> I tried excluding all sun/awt/X11 classes in >>>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>>> platforms still using X11 and I couldn't use the big list of >>>>>>> excluded files on Mac as that resulted in Java compilation errors, >>>>>>> so I just added some logic to exclude everything on Mac and left >>>>>>> the list in place everywhere else. >>>>>>> >>>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>>> symbols in JNI libs so that issue needs to be resolved first. I've >>>>>>> not had time to investigate that problem. >>>>>>> >>>>>>> >>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>> 461 } else { >>>>>>> 462 // TODO: do we still need this? >>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>> 464 } >>>>>>> >>>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>>> headless and headful modes I would think we could remove the >>>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>>> >>>>>>> >>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>>> both seem to be working fine. >>>>>>> >>>>>>> JPRT run for Mac is in progress, I will submit one for all other >>>>>>> platforms when it finishes building. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>> >>>> >>> From Sergey.Bylokhov at oracle.com Tue Oct 22 11:01:11 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 22:01:11 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BBDA.2010106@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> Message-ID: <5266BD67.4010101@oracle.com> Hello. I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). On 22.10.2013 21:54, Anthony Petrov wrote: > We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. > > Since we must load the lwawt lib in headless on Mac anyway, we may as > well use the CToolkit (properly wrapped in the HeadlessToolkit). But > there's no need to continue to use the HToolkit on Mac. > > -- > best regards, > Anthony > > On 10/22/2013 08:22 PM, Leonid Romanov wrote: >> There was a discussion why we use HToolkit instead of HeadlessToolkit: >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >> >> So we might want to continue using it. >> >> Also, please be aware that there is HToolkit check in >> GraphicsToolkit.getHeadlessProperty() >> >> On Oct 22, 2013, at 1:23 PM, Artem Ananiev >> wrote: >> >>> Hi, David, >>> >>> thanks for additional cleanup. >>> >>> I have only one concern. Before the fix, we checked if there is an >>> active Aqua session. When no session was found, we falled back to >>> HToolkit. I think this logic should be preserved, but slightly >>> corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>> >>> Otherwise the only way to run headless on Mac will be to force it >>> with the system property. It works this way on Windows, but on >>> Windows we're sure that WToolkit can run even without a UI session. >>> Is it also true on Mac? Did you try to launch AWT without >>> -Djava.awt.headless=true from remote console with no users logged in? >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>> >>>> Updated webrev for JDK (hotspot change is the same): >>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>> >>>> Changes since last version: >>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved >>>> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>> - Removed HToolkit option and toolkit selection code from >>>> java_props_macosx.[ch] >>>> >>>> -DrD- >>>> >>>> >>>>> I want to do one more iteration of this. Based on feedback it >>>>> seems I can remove a bit more code from java_props_macosx.[ch] and >>>>> make things a bit cleaner. >>>>> >>>>> -DrD- >>>>> >>>>>> Thanks guys. >>>>>> >>>>>> Anthony, can you sponsor this for me? >>>>>> >>>>>> -DrD- >>>>>> >>>>>>> This fix looks fine to me as well. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>> >>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>> >>>>>>>> Request for review of JDK-8025673: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>> >>>>>>>> Proposed changes: >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>> >>>>>>>> This change disables building libawt_xawt.dylib and >>>>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>>>> supported. There are too many challenges (and not enough time) >>>>>>>> in removing all X11 code from the Mac build at this time, so >>>>>>>> we're deferring complete removal for later (will be covered by >>>>>>>> JDK-8003900). >>>>>>>> >>>>>>>> A small change to hotspot is required as it was looking for >>>>>>>> libawt_xawt.dylib and if not found would set java.awt.headless >>>>>>>> to true. Since we don't build a headless only JRE on Mac I just >>>>>>>> have that method return false. I'm not sure how to handle >>>>>>>> changes to hotspot, can it be pushed along with the jdk >>>>>>>> changes? Without that change the Mac builds will be broken. >>>>>>>> >>>>>>>> Significant build system changes, build-dev guys are encouraged >>>>>>>> to comment... >>>>>>>> >>>>>>>> I tried excluding all sun/awt/X11 classes in >>>>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>>>> platforms still using X11 and I couldn't use the big list of >>>>>>>> excluded files on Mac as that resulted in Java compilation >>>>>>>> errors, so I just added some logic to exclude everything on Mac >>>>>>>> and left the list in place everywhere else. >>>>>>>> >>>>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>>>> symbols in JNI libs so that issue needs to be resolved first. >>>>>>>> I've not had time to investigate that problem. >>>>>>>> >>>>>>>> >>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>> 461 } else { >>>>>>>> 462 // TODO: do we still need this? >>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>> 464 } >>>>>>>> >>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>>>> headless and headful modes I would think we could remove the >>>>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>>>> >>>>>>>> >>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>>>> both seem to be working fine. >>>>>>>> >>>>>>>> JPRT run for Mac is in progress, I will submit one for all >>>>>>>> other platforms when it finishes building. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>> >>>>> >>>> >> -- Best regards, Sergey. From yekaterina.kantserova at oracle.com Tue Oct 22 01:24:19 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 22 Oct 2013 10:24:19 +0200 Subject: Fwd: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <526546FD.5020909@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> Message-ID: <52663633.2080206@oracle.com> Sorry, the wrong webrev link has slipped through. Here is the right one: http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ Thanks, Katja On 10/21/2013 05:23 PM, Yekaterina Kantserova wrote: > Hi, > > I've done following changes after the reviews: > - added open copyrights > - documented all public functions in jdk.testlibrary.TestThread, > jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils > - merged jdk.testlibrary.Asserts from hotspot testlibrary > > Jaroslav's comments: > - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, > different exception can show up there while waiting until jstatd is up > and running; better just look for valid pid; > - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since > jstatd process is daemon, the "clean up" is to kill the target > process. Please look at the changed JstatdHelper and tell me if it's > still unclear. > - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() > should be called in "finally" - fixed > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja From david.holmes at oracle.com Tue Oct 22 19:21:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Oct 2013 12:21:23 +1000 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <526732A3.5030201@oracle.com> Hi Erik, Sorry I hadn't had a chance to get back to this. This new approach seems fine - though I had to convince myself of the no GC can occur part :) A couple of typos: JvmtiBreakpoint:s The :s should just be s Thanks, David On 21/10/2013 7:26 PM, Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik > From david.dehaven at oracle.com Tue Oct 22 21:10:49 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 21:10:49 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BD67.4010101@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> Message-ID: <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> Updated webrev: http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ Summary of changes since last: - Added awt_headless to java_props_t (set to NULL by default which does not set the property) - Replaced the toolkit selection code in java_props_macosx.[ch]. I could have just exposed isAquaSession but I wanted to preserve the AWT_TOOLKIT environment variable support (no idea if it's actually used or not...). - Modified WrappedToolkitTest.sh to check that it's wrapping LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless jtreg tests pass. No build system or hotspot changes since the last patch. -DrD- From david.holmes at oracle.com Tue Oct 22 21:52:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Oct 2013 14:52:26 +1000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> Message-ID: <5267560A.1010800@oracle.com> On 23/10/2013 2:10 PM, David DeHaven wrote: > > Updated webrev: > > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ > > Summary of changes since last: > - Added awt_headless to java_props_t (set to NULL by default which does not set the property) Not sure about this part. We already force this property to be set in Embedded without needing any changes in the code you have modified and I'm not sure if your changes will break what we already do. Why do you need to do it? I'm getting concerned about this change touching stuff outside of OSX. David > - Replaced the toolkit selection code in java_props_macosx.[ch]. I could have just exposed isAquaSession but I wanted to preserve the AWT_TOOLKIT environment variable support (no idea if it's actually used or not...). > - Modified WrappedToolkitTest.sh to check that it's wrapping LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless jtreg tests pass. > > No build system or hotspot changes since the last patch. > > -DrD- > From staffan.larsen at oracle.com Wed Oct 23 03:55:57 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 12:55:57 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <52663633.2080206@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> <52663633.2080206@oracle.com> Message-ID: <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> test/lib/testlibrary/jdk/testlibrary/Asserts.java Same code as already exists in the hotspot testlibrary. No further comments. test/lib/testlibrary/jdk/testlibrary/ProcessThread.java L33: stating -> starting L66: staring -> starting test/lib/testlibrary/jdk/testlibrary/TestThread.java This code comes from an internal test library. No further comments. test/lib/testlibrary/jdk/testlibrary/Utils.java No comments. test/lib/testlibrary/jdk/testlibrary/XRun.java This code comes from an internal test library. No further comments. test/sun/tools/jstatd/JstatGcutilParser.java The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? L67: getType() should be private. test/sun/tools/jstatd/JstatdHelper.java: L54: Does verifyJpsOutput() work correctly with output of the form: 1234 -- main class information unavailable 1235 -- process information unavailable Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? test/sun/tools/jstatd/TestJstatdDefaults.java test/sun/tools/jstatd/TestJstatdExternalRegistry.java test/sun/tools/jstatd/TestJstatdPort.java test/sun/tools/jstatd/TestJstatdPortAndServer.java test/sun/tools/jstatd/TestJstatdServer.java No comments. test/sun/tools/jstatd/TestJstatdUsage.java Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. test/sun/tools/jstatd/ToolConfig.java ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? General comments: Can't we do: * @library /lib/testlibrary instead of * @library ../../../lib/testlibrary ? It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. Thanks, /Staffan On 22 okt 2013, at 10:24, Yekaterina Kantserova wrote: > Sorry, the wrong webrev link has slipped through. > > Here is the right one: > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ > > Thanks, > Katja > > > > On 10/21/2013 05:23 PM, Yekaterina Kantserova wrote: >> Hi, >> >> I've done following changes after the reviews: >> - added open copyrights >> - documented all public functions in jdk.testlibrary.TestThread, jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils >> - merged jdk.testlibrary.Asserts from hotspot testlibrary >> >> Jaroslav's comments: >> - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, different exception can show up there while waiting until jstatd is up and running; better just look for valid pid; >> - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since jstatd process is daemon, the "clean up" is to kill the target process. Please look at the changed JstatdHelper and tell me if it's still unclear. >> - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() should be called in "finally" - fixed >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Wed Oct 23 04:12:54 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 13:12:54 +0200 Subject: Fwd: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <526546FD.5020909@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> Message-ID: <5267AF36.3030201@oracle.com> Hi Katja, On 21.10.2013 17:23, Yekaterina Kantserova wrote: > Hi, > > I've done following changes after the reviews: > - added open copyrights > - documented all public functions in jdk.testlibrary.TestThread, > jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils > - merged jdk.testlibrary.Asserts from hotspot testlibrary > > Jaroslav's comments: > - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, different > exception can show up there while waiting until jstatd is up and > running; better just look for valid pid; > - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since > jstatd process is daemon, the "clean up" is to kill the target process. > Please look at the changed JstatdHelper and tell me if it's still unclear. > - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() > should be called in "finally" - fixed Thanks. I have no further comments. -JB- > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja > From gerard.ziemski at oracle.com Wed Oct 23 07:20:52 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 23 Oct 2013 09:20:52 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 Message-ID: <5267DB44.5090108@oracle.com> Please review this proposed workaround for OS X 10.9 (Mavericks) Description: On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns 128 pages for both main (primodial, primary) and secondary threads, when in fact 2048 pages are available for the main thread. pthread_get_stacksize_np() correctly returns 2048 pages for main thread on 10.6, 10.7 and 10.8 and probably all previous OS X versions. An issue has been filed with Apple, but in the meantime we need to substitute 2048 pages whenever pthread_get_stacksize_np() returns anything else (ie. 128) on main thread. The workaround uses hardcoded value of 2048 pages for main thread, because: 1. The correct value can in fact be found at runtime using signals (please see my test case attached to the bug's JDK issue), however, such code needs signal handlers and also takes about 3.5 ms, so it's probably not a viable solution. 2. We could also look-up OS X version at runtime to only use the workaround for 10.9, but that requires parsing an xml file, looking for a value that is internationalized, so it's non trivial (though might be doable assuming the time to execute is low enough) 3. All JDK8 supported OS X versions (ie. 10.7, 10.8) return 2048. In the future, this workaround might need to be revisited (ie. 2), but I believe that it's reasonable for now, though I would love to hear others opinions on this. Testing: In progress... References: http://cr.openjdk.java.net/~iklam/8020753/ziemski_rev1/ https://bugs.openjdk.java.net/browse/JDK-8020753 cheers From artem.ananiev at oracle.com Wed Oct 23 08:11:47 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 23 Oct 2013 19:11:47 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267C247.7040708@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> Message-ID: <5267E733.8010905@oracle.com> On 10/23/2013 4:34 PM, Anthony Petrov wrote: > On 10/23/2013 08:52 AM, David Holmes wrote: >> On 23/10/2013 2:10 PM, David DeHaven wrote: >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>> >>> Summary of changes since last: >>> - Added awt_headless to java_props_t (set to NULL by default which >>> does not set the property) >> >> Not sure about this part. We already force this property to be set in >> Embedded without needing any changes in the code you have modified and >> I'm not sure if your changes will break what we already do. Why do you >> need to do it? >> >> I'm getting concerned about this change touching stuff outside of OSX. > > I think I agree with David. E.g. I'm not sure I like changing > j/l/System.c for this fix. > > Given the time constraints, perhaps going with HToolkit would be a good > enough solution for now? > > Artem, what's your opinion? I'm personally fine with the current version. The fix is now Mac OS X specific, as sprops.awt_headless is only set within #ifdef MACOSX, it won't have any impact on other platforms. At the same time it enables headless functionality on Mac OS X, while HToolkit doesn't. Note that it can be improved further. As it stands now, the only purpose of getPreferredToolkit() is to check if Aqua session is active. The toolkit we use is always CToolkit, regardless of what this method returns, so the method can be removed, and isInAquaSession() can be called instead. Leaving this further cleanup up to David D., though. Thanks, Artem > -- > best regards, > Anthony > >> >> David >> >>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>> could have just exposed isAquaSession but I wanted to preserve the >>> AWT_TOOLKIT environment variable support (no idea if it's actually >>> used or not...). >>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>> jtreg tests pass. >>> >>> No build system or hotspot changes since the last patch. >>> >>> -DrD- >>> From david.dehaven at oracle.com Wed Oct 23 09:49:09 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 23 Oct 2013 09:49:09 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267E733.8010905@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> Message-ID: <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> >>> Not sure about this part. We already force this property to be set in >>> Embedded without needing any changes in the code you have modified and >>> I'm not sure if your changes will break what we already do. Why do you >>> need to do it? >>> >>> I'm getting concerned about this change touching stuff outside of OSX. >> >> I think I agree with David. E.g. I'm not sure I like changing >> j/l/System.c for this fix. >> >> Given the time constraints, perhaps going with HToolkit would be a good >> enough solution for now? >> >> Artem, what's your opinion? > > I'm personally fine with the current version. The fix is now Mac OS X specific, as sprops.awt_headless is only set within #ifdef MACOSX, it won't have any impact on other platforms. At the same time it enables headless functionality on Mac OS X, while HToolkit doesn't. > > Note that it can be improved further. As it stands now, the only purpose of getPreferredToolkit() is to check if Aqua session is active. The toolkit we use is always CToolkit, regardless of what this method returns, so the method can be removed, and isInAquaSession() can be called instead. Leaving this further cleanup up to David D., though. The only reason I left it in there was for the AWT_TOOLKIT environment variable support. Right now if you set AWT_TOOLKIT to HToolkit it will start in headless mode regardless of what isAquaSession() returns. If we don't care about that then I'll happily remove it (I'm asking because I don't know if it's used or not). For example: $ AWT_TOOLKIT=HToolkit ./build/macosx-x86_64-normal-server-release/jdk/bin/java -jar ~/Desktop/SwingSet2.jar 2013-10-23 09:26:21.726 java[23276:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. Exception in thread "main" java.awt.HeadlessException at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) at SwingSet2.main(SwingSet2.java:224) But it's *only* implemented on Mac OS X so it doesn't appear to be all that useful unless we want it implemented for other platforms, which would be a whole separate issue. Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. -DrD- From david.dehaven at oracle.com Wed Oct 23 10:00:24 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 23 Oct 2013 10:00:24 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267FF2D.5060804@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> Message-ID: >> The only reason I left it in there was for the AWT_TOOLKIT environment variable support. Right now if you set AWT_TOOLKIT to HToolkit it will start in headless mode regardless of what isAquaSession() returns. If we don't care about that then I'll happily remove it (I'm asking because I don't know if it's used or not). >> >> For example: >> $ AWT_TOOLKIT=HToolkit ./build/macosx-x86_64-normal-server-release/jdk/bin/java -jar ~/Desktop/SwingSet2.jar >> 2013-10-23 09:26:21.726 java[23276:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. >> Exception in thread "main" java.awt.HeadlessException >> at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) >> at SwingSet2.main(SwingSet2.java:224) >> >> But it's *only* implemented on Mac OS X so it doesn't appear to be all that useful unless we want it implemented for other platforms, which would be a whole separate issue. > > There's a documented way to choose a toolkit: it is the awt.toolkit system property. > > We don't care about AWT_TOOLKIT anymore. It was only relevant at the time of 1.5 and 1.6 to allow users to switch between MToolkit and XToolkit. Now that MToolkit is gone, this environment variable isn't needed. Ah, ok. That makes sense. In that case we can nuke most of what I just put back :) >> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. > > I like this idea. But it needs testing. Cool, I'll poke at it when I get a chance. -DrD- From igor.veresov at oracle.com Wed Oct 23 11:41:43 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 23 Oct 2013 11:41:43 -0700 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 In-Reply-To: <5267DB44.5090108@oracle.com> References: <5267DB44.5090108@oracle.com> Message-ID: <2E94A7FB-8F0C-4996-8EF0-8DA5E1040B4E@oracle.com> I guess it's reasonable. As for option (2) you can probably trigger the fix based on the kernel version, that is rather easy to get: #include #include char str[256]; size_t size = sizeof(str); int ret = sysctlbyname("kern.osrelease", str, &size, NULL, 0); Versions 13.x.x would be Mavericks. You can use it to put an additional assert. igor On Oct 23, 2013, at 7:20 AM, Gerard Ziemski wrote: > Please review this proposed workaround for OS X 10.9 (Mavericks) > > Description: > > On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns 128 pages for both main (primodial, primary) and secondary threads, when in fact 2048 pages are available for the main thread. pthread_get_stacksize_np() correctly returns 2048 pages for main thread on 10.6, 10.7 and 10.8 and probably all previous OS X versions. > > An issue has been filed with Apple, but in the meantime we need to substitute 2048 pages whenever pthread_get_stacksize_np() returns anything else (ie. 128) on main thread. > > The workaround uses hardcoded value of 2048 pages for main thread, because: > > 1. The correct value can in fact be found at runtime using signals (please see my test case attached to the bug's JDK issue), however, such code needs signal handlers and also takes about 3.5 ms, so it's probably not a viable solution. > > 2. We could also look-up OS X version at runtime to only use the workaround for 10.9, but that requires parsing an xml file, looking for a value that is internationalized, so it's non trivial (though might be doable assuming the time to execute is low enough) > > 3. All JDK8 supported OS X versions (ie. 10.7, 10.8) return 2048. > > In the future, this workaround might need to be revisited (ie. 2), but I believe that it's reasonable for now, though I would love to hear others opinions on this. > > > Testing: > > In progress... > > > References: > > http://cr.openjdk.java.net/~iklam/8020753/ziemski_rev1/ > https://bugs.openjdk.java.net/browse/JDK-8020753 > > > cheers > From gerard.ziemski at oracle.com Wed Oct 23 13:04:56 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 23 Oct 2013 15:04:56 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 In-Reply-To: <2E94A7FB-8F0C-4996-8EF0-8DA5E1040B4E@oracle.com> References: <5267DB44.5090108@oracle.com> <2E94A7FB-8F0C-4996-8EF0-8DA5E1040B4E@oracle.com> Message-ID: <52682BE8.8090604@oracle.com> I like that check - the issue lies inside the kernel most likely, so any fix would end up reving up the kernel version. Thank you. On 10/23/2013 1:41 PM, Igor Veresov wrote: > I guess it's reasonable. > > As for option (2) you can probably trigger the fix based on the kernel > version, that is rather easy to get: > > #include > #include > char str[256]; > size_t size = sizeof(str); > int ret = sysctlbyname("kern.osrelease", str, &size, NULL, 0); > > Versions 13.x.x would be Mavericks. You can use it to put an > additional assert. > > igor > > > > > On Oct 23, 2013, at 7:20 AM, Gerard Ziemski > wrote: > >> Please review this proposed workaround for OS X 10.9 (Mavericks) >> >> Description: >> >> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API >> returns 128 pages for both main (primodial, primary) and secondary >> threads, when in fact 2048 pages are available for the main thread. >> pthread_get_stacksize_np() correctly returns 2048 pages for main >> thread on 10.6, 10.7 and 10.8 and probably all previous OS X versions. >> >> An issue has been filed with Apple, but in the meantime we need to >> substitute 2048 pages whenever pthread_get_stacksize_np() returns >> anything else (ie. 128) on main thread. >> >> The workaround uses hardcoded value of 2048 pages for main thread, >> because: >> >> 1. The correct value can in fact be found at runtime using signals >> (please see my test case attached to the bug's JDK issue), however, >> such code needs signal handlers and also takes about 3.5 ms, so it's >> probably not a viable solution. >> >> 2. We could also look-up OS X version at runtime to only use the >> workaround for 10.9, but that requires parsing an xml file, looking >> for a value that is internationalized, so it's non trivial (though >> might be doable assuming the time to execute is low enough) >> >> 3. All JDK8 supported OS X versions (ie. 10.7, 10.8) return 2048. >> >> In the future, this workaround might need to be revisited (ie. 2), >> but I believe that it's reasonable for now, though I would love to >> hear others opinions on this. >> >> >> Testing: >> >> In progress... >> >> >> References: >> >> http://cr.openjdk.java.net/~iklam/8020753/ziemski_rev1/ >> >> https://bugs.openjdk.java.net/browse/JDK-8020753 >> >> >> cheers >> > From alejandro.murillo at oracle.com Wed Oct 23 13:53:48 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 20:53:48 +0000 Subject: hg: hsx/jdk7u/hotspot: 76 new changesets Message-ID: <20131023205648.6A013626A5@hg.openjdk.java.net> Changeset: bf3a8b634b75 Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/bf3a8b634b75 Added tag jdk7u40-b60 for changeset af1fc2868a2b ! .hgtags Changeset: 59ac98b236e9 Author: amurillo Date: 2013-10-08 09:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/59ac98b236e9 Merge ! .hgtags Changeset: de9d6e30ae65 Author: amurillo Date: 2013-10-09 02:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/de9d6e30ae65 Merge ! .hgtags Changeset: b80a290e6e30 Author: katleman Date: 2013-06-11 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b80a290e6e30 Added tag jdk7u25-b30 for changeset 97a3ebd62052 ! .hgtags Changeset: 273e8afccd6e Author: katleman Date: 2013-06-12 20:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/273e8afccd6e Added tag jdk7u25-b16 for changeset b80a290e6e30 ! .hgtags Changeset: fbdcfe2b22f7 Author: katleman Date: 2013-06-14 18:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/fbdcfe2b22f7 Added tag jdk7u25-b32 for changeset 273e8afccd6e ! .hgtags Changeset: d85fda0cb63d Author: amurillo Date: 2013-06-22 01:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d85fda0cb63d Merge ! .hgtags ! make/hotspot_version ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/prims/jvm.cpp Changeset: 5fb434aa203c Author: asaha Date: 2013-06-28 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/5fb434aa203c Merge ! .hgtags ! make/hotspot_version ! src/share/vm/memory/allocation.hpp Changeset: 2eb5b21ae3a2 Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2eb5b21ae3a2 Added tag jdk7u45-b01 for changeset 5fb434aa203c ! .hgtags Changeset: 3a431edfd80e Author: asaha Date: 2013-07-03 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/3a431edfd80e Merge ! .hgtags ! make/hotspot_version - test/compiler/8011901/Test8011901.java Changeset: f2039061ba49 Author: asaha Date: 2013-07-08 15:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f2039061ba49 8020088: Increment minor version of HSx for 7u45 and initialize the build number Reviewed-by: jcoomes ! make/hotspot_version Changeset: aaa90a89968d Author: katleman Date: 2013-07-09 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/aaa90a89968d Added tag jdk7u45-b02 for changeset f2039061ba49 ! .hgtags Changeset: a3bbc959356e Author: asaha Date: 2013-07-10 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a3bbc959356e Merge ! .hgtags ! make/hotspot_version Changeset: 28e475dfa88b Author: sgabdura Date: 2013-07-15 10:22 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/28e475dfa88b 8016256: Make finalization final Reviewed-by: hseigel ! src/share/vm/classfile/classFileParser.cpp Changeset: d6fd3f84a30c Author: asaha Date: 2013-07-15 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d6fd3f84a30c 8020551: increment hsx build to b03 for 7u45-b03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d77632370b2c Author: cl Date: 2013-07-16 05:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d77632370b2c Added tag jdk7u45-b03 for changeset d6fd3f84a30c ! .hgtags Changeset: 7f16aa906738 Author: asaha Date: 2013-07-19 21:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/7f16aa906738 Merge ! .hgtags ! make/hotspot_version Changeset: 9ee0d96a61f7 Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/9ee0d96a61f7 Added tag jdk7u45-b04 for changeset 7f16aa906738 ! .hgtags Changeset: 99cd2b514c4d Author: asaha Date: 2013-07-25 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/99cd2b514c4d Merge ! .hgtags ! make/hotspot_version ! src/share/vm/memory/allocation.hpp Changeset: 2f9e4153cc9c Author: asaha Date: 2013-07-29 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2f9e4153cc9c Merge Changeset: 107f15f2f32f Author: asaha Date: 2013-07-30 08:43 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/107f15f2f32f Merge ! .hgtags ! make/hotspot_version Changeset: 1db90c27640c Author: asaha Date: 2013-07-30 10:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1db90c27640c 8021901: Increment hsx build to b05 for 7u45-b05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b4fe146b820b Author: asaha Date: 2013-07-31 23:04 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b4fe146b820b Merge ! .hgtags Changeset: b265ae7b2536 Author: asaha Date: 2013-08-02 15:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b265ae7b2536 Added tag jdk7u45-b05 for changeset b4fe146b820b ! .hgtags Changeset: a70c27cf8d8d Author: asaha Date: 2013-08-02 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a70c27cf8d8d Merge ! .hgtags Changeset: 04cb4c80f821 Author: cl Date: 2013-08-02 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/04cb4c80f821 Added tag jdk7u45-b05 for changeset 99cd2b514c4d ! .hgtags Changeset: 2a71de92a52b Author: asaha Date: 2013-08-05 11:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2a71de92a52b 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: 5283790fa36a Author: asaha Date: 2013-08-05 13:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/5283790fa36a Merge ! .hgtags Changeset: 63efa616e54d Author: asaha Date: 2013-08-07 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/63efa616e54d Merge ! .hgtags Changeset: 3b126aa4940b Author: cl Date: 2013-08-08 23:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/3b126aa4940b Added tag jdk7u45-b06 for changeset 63efa616e54d ! .hgtags Changeset: f6748e6123b6 Author: asaha Date: 2013-08-12 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f6748e6123b6 Merge ! .hgtags Changeset: e5f31f17096f Author: cl Date: 2013-08-15 22:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/e5f31f17096f Added tag jdk7u45-b07 for changeset f6748e6123b6 ! .hgtags Changeset: c228c923f141 Author: asaha Date: 2013-08-19 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c228c923f141 Merge ! .hgtags Changeset: cf07fdc3ad19 Author: asaha Date: 2013-08-19 20:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/cf07fdc3ad19 8023323: Increment hsx build to b06 for 7u45-b08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 75c36a461ecd Author: erikj Date: 2013-08-19 17:50 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/75c36a461ecd 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 06bcab9ef183 Author: asaha Date: 2013-08-19 20:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/06bcab9ef183 Merge Changeset: da0fd3b6c5b0 Author: cl Date: 2013-08-20 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/da0fd3b6c5b0 Added tag jdk7u45-b08 for changeset 06bcab9ef183 ! .hgtags Changeset: d69c8260dd7c Author: asaha Date: 2013-08-22 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d69c8260dd7c Merge ! .hgtags Changeset: b8a4430c2848 Author: asaha Date: 2013-08-26 08:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b8a4430c2848 Merge ! .hgtags Changeset: d11e481d58a1 Author: asaha Date: 2013-08-26 09:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d11e481d58a1 8023741: Increment hsx 24.45 build to b07 for 7u45-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 565e6fdc63f3 Author: sla Date: 2013-08-21 13:18 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/565e6fdc63f3 8022808: Kitchensink hangs on macos Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources Reviewed-by: dholmes, rbackman ! src/os/bsd/vm/os_bsd.cpp Changeset: 306a8b39b345 Author: mgronlun Date: 2013-08-23 13:52 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/306a8b39b345 8023457: Event based tracing framework needs a mutex for thread groups Reviewed-by: acorn, sla ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 996b6863b3b2 Author: asaha Date: 2013-08-26 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/996b6863b3b2 Merge Changeset: 956a9282d989 Author: cl Date: 2013-08-27 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/956a9282d989 Added tag jdk7u45-b09 for changeset 996b6863b3b2 ! .hgtags Changeset: ddf4086a9118 Author: asaha Date: 2013-08-27 22:28 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ddf4086a9118 8023888: Increment hsx 24.45 build to b08 for 7u45-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 45c4d9353387 Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/45c4d9353387 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 319bfff22782 Author: asaha Date: 2013-08-27 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/319bfff22782 Merge Changeset: 7b028a5f4882 Author: asaha Date: 2013-08-27 22:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/7b028a5f4882 Merge Changeset: bcaf889eea9e Author: asaha Date: 2013-08-30 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/bcaf889eea9e Merge ! .hgtags ! make/hotspot_version Changeset: b8266091df35 Author: cl Date: 2013-09-04 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b8266091df35 Added tag jdk7u45-b10 for changeset bcaf889eea9e ! .hgtags Changeset: 7ca907428850 Author: asaha Date: 2013-09-04 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/7ca907428850 Merge ! .hgtags Changeset: ed1505510ea0 Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ed1505510ea0 Added tag jdk7u45-b11 for changeset 7ca907428850 ! .hgtags Changeset: 89f99af7a7bb Author: cl Date: 2013-09-18 02:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/89f99af7a7bb Added tag jdk7u45-b12 for changeset ed1505510ea0 ! .hgtags Changeset: 718d1e9223dd Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/718d1e9223dd Added tag jdk7u45-b13 for changeset 89f99af7a7bb ! .hgtags Changeset: 9ad76a08e5ed Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/9ad76a08e5ed Added tag jdk7u45-b14 for changeset 718d1e9223dd ! .hgtags Changeset: 429884602206 Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/429884602206 Added tag jdk7u45-b15 for changeset 9ad76a08e5ed ! .hgtags Changeset: 79d6c7579df1 Author: asaha Date: 2013-10-01 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/79d6c7579df1 Merge ! .hgtags Changeset: 06fd4dba2fb8 Author: asaha Date: 2013-10-08 13:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/06fd4dba2fb8 Merge ! .hgtags ! make/hotspot_version Changeset: 09fa1c144a13 Author: asaha Date: 2013-09-05 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/09fa1c144a13 8024369: Increment build # of hs24.0 to b57 for 7u40-b61 psu Reviewed-by: jcoomes ! make/hotspot_version Changeset: efaa26fb6de2 Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/efaa26fb6de2 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp Changeset: 81bc06715f6c Author: katleman Date: 2013-09-11 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/81bc06715f6c Added tag jdk7u40-b61 for changeset efaa26fb6de2 ! .hgtags Changeset: df6f37a7311d Author: kevinw Date: 2013-09-16 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/df6f37a7311d 8023478: Test fails with HS crash in GCNotifier. Reviewed-by: sla ! src/share/vm/services/gcNotifier.cpp Changeset: c75d07d80623 Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c75d07d80623 Added tag jdk7u40-b62 for changeset df6f37a7311d ! .hgtags Changeset: a61d36ab0338 Author: asaha Date: 2013-09-19 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a61d36ab0338 Merge ! .hgtags ! make/hotspot_version Changeset: bdf64a0126d4 Author: asaha Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/bdf64a0126d4 Merge ! .hgtags Changeset: 0c0dc384915c Author: cl Date: 2013-10-03 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/0c0dc384915c Added tag jdk7u45-b16 for changeset 429884602206 ! .hgtags Changeset: 12374864c655 Author: cl Date: 2013-10-07 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/12374864c655 Added tag jdk7u45-b17 for changeset 0c0dc384915c ! .hgtags Changeset: 3677c8cc3c89 Author: cl Date: 2013-10-08 09:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/3677c8cc3c89 Added tag jdk7u45-b18 for changeset 12374864c655 ! .hgtags Changeset: be31e93e1279 Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/be31e93e1279 Added tag jdk7u45-b30 for changeset 3677c8cc3c89 ! .hgtags Changeset: 520b7b3d9153 Author: asaha Date: 2013-10-08 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/520b7b3d9153 Merge ! .hgtags Changeset: c5aa485b50d6 Author: asaha Date: 2013-10-08 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c5aa485b50d6 Merge ! .hgtags ! make/hotspot_version Changeset: c373a733d5d5 Author: cl Date: 2013-10-09 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c373a733d5d5 Added tag jdk7u45-b31 for changeset 520b7b3d9153 ! .hgtags Changeset: d14c8535e856 Author: asaha Date: 2013-10-09 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d14c8535e856 Merge ! .hgtags Changeset: eeef89c7279e Author: asaha Date: 2013-10-14 23:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/eeef89c7279e Merge ! .hgtags Changeset: b7d44793cd26 Author: amurillo Date: 2013-10-23 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b7d44793cd26 Merge ! make/hotspot_version ! src/os/bsd/vm/os_bsd.cpp Changeset: a03f20e7b0fc Author: amurillo Date: 2013-10-23 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a03f20e7b0fc Added tag hs24.60-b02 for changeset b7d44793cd26 ! .hgtags From alejandro.murillo at oracle.com Wed Oct 23 15:27:08 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 22:27:08 +0000 Subject: hg: hsx/jdk7u/corba: 61 new changesets Message-ID: <20131023222753.9074D626B5@hg.openjdk.java.net> Changeset: 14911db77f95 Author: coffeys Date: 2013-09-03 22:35 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/14911db77f95 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: 504acad33722 Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/504acad33722 Added tag jdk7u40-b60 for changeset 08737d863a7a ! .hgtags Changeset: b467f5b58bbc Author: coffeys Date: 2013-09-23 12:06 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b467f5b58bbc Merge Changeset: 377d9cfb6fa1 Author: lana Date: 2013-10-09 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/377d9cfb6fa1 Merge ! .hgtags Changeset: 8dddd1c2fd9e Author: msheppar Date: 2013-06-14 17:45 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8dddd1c2fd9e 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: fc434680b23c Author: asaha Date: 2013-06-19 21:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/fc434680b23c Merge Changeset: 96c4e7c84230 Author: asaha Date: 2013-06-20 21:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/96c4e7c84230 Merge ! .hgtags Changeset: 4f54264ca4df Author: asaha Date: 2013-06-21 21:56 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/4f54264ca4df Merge ! .hgtags Changeset: eb228b67522e Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/eb228b67522e Added tag jdk7u45-b01 for changeset 4f54264ca4df ! .hgtags Changeset: 8c4894c44f92 Author: asaha Date: 2013-07-02 15:25 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8c4894c44f92 Merge ! .hgtags Changeset: 462d171e9097 Author: asaha Date: 2013-07-02 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/462d171e9097 Merge ! .hgtags Changeset: 1a1a1dedf437 Author: asaha Date: 2013-07-03 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/1a1a1dedf437 Merge ! .hgtags Changeset: 43cf19188238 Author: katleman Date: 2013-07-09 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/43cf19188238 Added tag jdk7u45-b02 for changeset 1a1a1dedf437 ! .hgtags Changeset: 3a2cca8c2f20 Author: asaha Date: 2013-07-10 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3a2cca8c2f20 Merge ! .hgtags Changeset: 38acb2b8e5c5 Author: cl Date: 2013-07-16 05:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/38acb2b8e5c5 Added tag jdk7u45-b03 for changeset 3a2cca8c2f20 ! .hgtags Changeset: 8cce3b403b3e Author: mchung Date: 2013-07-18 17:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8cce3b403b3e 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: 7cfa75064d07 Author: asaha Date: 2013-07-17 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/7cfa75064d07 Merge ! .hgtags Changeset: 4f4f7869bd65 Author: asaha Date: 2013-07-22 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/4f4f7869bd65 Merge Changeset: 7fd80a3a030b Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/7fd80a3a030b Added tag jdk7u45-b04 for changeset 4f4f7869bd65 ! .hgtags Changeset: 4e6f135b2779 Author: asaha Date: 2013-07-25 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/4e6f135b2779 Merge ! .hgtags Changeset: b23aed280f64 Author: asaha Date: 2013-07-29 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b23aed280f64 Merge Changeset: faee62d13040 Author: asaha Date: 2013-07-31 23:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/faee62d13040 Merge ! .hgtags Changeset: 45f6e6fc71c4 Author: asaha Date: 2013-08-02 15:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/45f6e6fc71c4 Added tag jdk7u45-b05 for changeset faee62d13040 ! .hgtags Changeset: b7baf058aef2 Author: asaha Date: 2013-08-02 15:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b7baf058aef2 Merge ! .hgtags Changeset: a23c053ff460 Author: cl Date: 2013-08-02 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/a23c053ff460 Added tag jdk7u45-b05 for changeset 4e6f135b2779 ! .hgtags Changeset: b2871fcc688f Author: asaha Date: 2013-08-05 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b2871fcc688f 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: 37de564abe4c Author: asaha Date: 2013-08-05 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/37de564abe4c Merge ! .hgtags Changeset: 435dd0e1ab9e Author: asaha Date: 2013-08-07 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/435dd0e1ab9e Merge ! .hgtags Changeset: fb777d9d95dc Author: cl Date: 2013-08-08 23:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/fb777d9d95dc Added tag jdk7u45-b06 for changeset 435dd0e1ab9e ! .hgtags Changeset: 2e19615f6045 Author: asaha Date: 2013-08-12 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/2e19615f6045 Merge ! .hgtags Changeset: a2ac8c815b06 Author: cl Date: 2013-08-15 22:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/a2ac8c815b06 Added tag jdk7u45-b07 for changeset 2e19615f6045 ! .hgtags Changeset: 771c5c869d16 Author: asaha Date: 2013-08-19 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/771c5c869d16 Merge ! .hgtags Changeset: 30130bd0e11e Author: cl Date: 2013-08-20 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/30130bd0e11e Added tag jdk7u45-b08 for changeset 771c5c869d16 ! .hgtags Changeset: 5f4c2a41513c Author: asaha Date: 2013-08-22 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/5f4c2a41513c Merge ! .hgtags Changeset: 366385ab5e9b Author: msheppar Date: 2013-08-19 17:01 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/366385ab5e9b 8022940: Enhance CORBA translations Reviewed-by: coffeys, alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java Changeset: 1a13a3a11b2e Author: asaha Date: 2013-08-20 10:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/1a13a3a11b2e Merge Changeset: c61913c4ad0a Author: asaha Date: 2013-08-22 08:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/c61913c4ad0a Merge Changeset: a89d69bef361 Author: asaha Date: 2013-08-26 08:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/a89d69bef361 Merge ! .hgtags Changeset: 1e450f9795be Author: cl Date: 2013-08-27 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/1e450f9795be Added tag jdk7u45-b09 for changeset a89d69bef361 ! .hgtags Changeset: fd8a2041b75c Author: asaha Date: 2013-08-27 15:13 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/fd8a2041b75c Merge ! .hgtags Changeset: 4723f2a4bf50 Author: cl Date: 2013-09-04 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/4723f2a4bf50 Added tag jdk7u45-b10 for changeset fd8a2041b75c ! .hgtags Changeset: 55e0d3d95143 Author: asaha Date: 2013-09-04 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/55e0d3d95143 Merge ! .hgtags Changeset: 336566c2905a Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/336566c2905a Added tag jdk7u45-b11 for changeset 55e0d3d95143 ! .hgtags Changeset: 6cadc3dd82a4 Author: cl Date: 2013-09-18 02:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/6cadc3dd82a4 Added tag jdk7u45-b12 for changeset 336566c2905a ! .hgtags Changeset: 43e22471d0c2 Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/43e22471d0c2 Added tag jdk7u45-b13 for changeset 6cadc3dd82a4 ! .hgtags Changeset: 3d7a52de59f0 Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3d7a52de59f0 Added tag jdk7u45-b14 for changeset 43e22471d0c2 ! .hgtags Changeset: b1f069eb48ed Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b1f069eb48ed Added tag jdk7u45-b15 for changeset 3d7a52de59f0 ! .hgtags Changeset: 10c82a89e8e8 Author: asaha Date: 2013-10-01 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/10c82a89e8e8 Merge ! .hgtags Changeset: c9c225fb19c3 Author: katleman Date: 2013-09-11 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/c9c225fb19c3 Added tag jdk7u40-b61 for changeset 504acad33722 ! .hgtags Changeset: a09bfe5b7f69 Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/a09bfe5b7f69 Added tag jdk7u40-b62 for changeset c9c225fb19c3 ! .hgtags Changeset: 19a9832f198c Author: asaha Date: 2013-09-19 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/19a9832f198c Merge ! .hgtags Changeset: 0e8dd12ebf65 Author: asaha Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/0e8dd12ebf65 Merge ! .hgtags Changeset: 8b8793f06c56 Author: cl Date: 2013-10-03 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8b8793f06c56 Added tag jdk7u45-b16 for changeset b1f069eb48ed ! .hgtags Changeset: 80f65a8f5850 Author: cl Date: 2013-10-07 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/80f65a8f5850 Added tag jdk7u45-b17 for changeset 8b8793f06c56 ! .hgtags Changeset: a15e4a545044 Author: cl Date: 2013-10-08 09:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/a15e4a545044 Added tag jdk7u45-b18 for changeset 80f65a8f5850 ! .hgtags Changeset: 264523aa4163 Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/264523aa4163 Added tag jdk7u45-b30 for changeset a15e4a545044 ! .hgtags Changeset: b7fb35bbe70d Author: asaha Date: 2013-10-08 11:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b7fb35bbe70d Merge ! .hgtags Changeset: c3a9d8ffbd69 Author: asaha Date: 2013-10-08 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/c3a9d8ffbd69 Merge ! .hgtags Changeset: d641ac83157e Author: cl Date: 2013-10-09 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/d641ac83157e Added tag jdk7u45-b31 for changeset b7fb35bbe70d ! .hgtags Changeset: 165543b65c3d Author: asaha Date: 2013-10-09 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/165543b65c3d Merge ! .hgtags Changeset: 47dded4c92d4 Author: asaha Date: 2013-10-14 23:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/47dded4c92d4 Merge ! .hgtags From alejandro.murillo at oracle.com Wed Oct 23 15:28:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 22:28:36 +0000 Subject: hg: hsx/jdk7u/jaxp: 66 new changesets Message-ID: <20131023223020.AA6DE626B6@hg.openjdk.java.net> Changeset: c500d4ec41ff Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/c500d4ec41ff Added tag jdk7u40-b60 for changeset 91bc45348512 ! .hgtags Changeset: 7ad0e91a96b2 Author: coffeys Date: 2013-09-23 12:07 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7ad0e91a96b2 Merge Changeset: 9d261303a659 Author: aefimov Date: 2013-10-01 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/9d261303a659 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java Changeset: c62352b6670e Author: lana Date: 2013-10-09 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/c62352b6670e Merge ! .hgtags Changeset: 151f24093998 Author: asaha Date: 2013-06-20 21:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/151f24093998 Merge ! .hgtags - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: e87d2da5c22e Author: asaha Date: 2013-06-21 21:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/e87d2da5c22e Merge ! .hgtags Changeset: 1a7e2024963d Author: asaha Date: 2013-06-28 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/1a7e2024963d Merge ! .hgtags Changeset: ac201a395412 Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/ac201a395412 Added tag jdk7u45-b01 for changeset 1a7e2024963d ! .hgtags Changeset: 8426c41b7922 Author: joehw Date: 2013-07-03 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/8426c41b7922 8012425: Transform TransformerFactory Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 72b314bf2ee1 Author: asaha Date: 2013-07-03 17:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/72b314bf2ee1 Merge ! .hgtags Changeset: 32a6df99656c Author: joehw Date: 2013-07-09 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/32a6df99656c 8017298: Better XML support Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/xml/internal/stream/Entity.java Changeset: 0f23a1e40a4c Author: katleman Date: 2013-07-09 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0f23a1e40a4c Added tag jdk7u45-b02 for changeset 72b314bf2ee1 ! .hgtags Changeset: 7548ce6c26ac Author: katleman Date: 2013-07-10 17:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7548ce6c26ac Merge - src/com/sun/org/apache/xerces/internal/util/SecurityManager.java Changeset: 2e6d1ceda5ee Author: asaha Date: 2013-07-10 17:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/2e6d1ceda5ee Merge ! .hgtags Changeset: 399c58bf22ad Author: joehw Date: 2013-07-11 09:01 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/399c58bf22ad 8013503: Improve stream factories Reviewed-by: alanb, dfuchs, mullan ! src/javax/xml/stream/FactoryFinder.java ! src/javax/xml/stream/XMLEventFactory.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/stream/XMLOutputFactory.java Changeset: 41b81353608d Author: cl Date: 2013-07-16 05:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/41b81353608d Added tag jdk7u45-b03 for changeset 399c58bf22ad ! .hgtags Changeset: e66ea9257ba8 Author: asaha Date: 2013-07-22 08:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/e66ea9257ba8 Merge ! .hgtags ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 8e3fc2c4d100 Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/8e3fc2c4d100 Added tag jdk7u45-b04 for changeset e66ea9257ba8 ! .hgtags Changeset: be81d5007d94 Author: asaha Date: 2013-07-25 17:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/be81d5007d94 Merge ! .hgtags Changeset: dc1f16423f11 Author: joehw Date: 2013-07-30 03:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/dc1f16423f11 8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing Reviewed-by: lancea, alanb, dfuchs, mullan ! src/com/sun/xml/internal/stream/Entity.java Changeset: d103a3b383ad Author: asaha Date: 2013-07-29 11:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/d103a3b383ad Merge ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: 81a6b4a47a92 Author: asaha Date: 2013-07-31 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/81a6b4a47a92 Merge Changeset: 1610b0a8cafe Author: asaha Date: 2013-07-31 23:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/1610b0a8cafe Merge ! .hgtags Changeset: 7b1609dc89e7 Author: joehw Date: 2013-07-30 01:19 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7b1609dc89e7 8014530: Better digital signature processing Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 010655015017 Author: joehw Date: 2013-07-30 03:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/010655015017 8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing Reviewed-by: lancea, alanb, dfuchs, mullan ! src/com/sun/xml/internal/stream/Entity.java Changeset: ae46ee9bbea0 Author: joehw Date: 2013-07-30 23:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/ae46ee9bbea0 8021933: Add extra check for fix # JDK-8014530 Reviewed-by: alanb, lancea ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java Changeset: 3a6dce39c05c Author: asaha Date: 2013-08-01 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/3a6dce39c05c Merge ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: f4fd1b4b9abc Author: asaha Date: 2013-08-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/f4fd1b4b9abc Added tag jdk7u45-b05 for changeset 3a6dce39c05c ! .hgtags Changeset: 853504c1e317 Author: asaha Date: 2013-08-02 22:25 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/853504c1e317 Merge ! .hgtags Changeset: be78d9f152cc Author: cl Date: 2013-08-02 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/be78d9f152cc Added tag jdk7u45-b05 for changeset ae46ee9bbea0 ! .hgtags Changeset: bf0795a73135 Author: asaha Date: 2013-08-05 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/bf0795a73135 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: 07be083abb61 Author: asaha Date: 2013-08-05 13:46 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/07be083abb61 Merge ! .hgtags Changeset: a7b1dcabdebb Author: asaha Date: 2013-08-07 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/a7b1dcabdebb Merge ! .hgtags Changeset: 04abe5fcf0fa Author: cl Date: 2013-08-08 23:24 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/04abe5fcf0fa Added tag jdk7u45-b06 for changeset a7b1dcabdebb ! .hgtags Changeset: 5a54c747be64 Author: asaha Date: 2013-08-12 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/5a54c747be64 Merge ! .hgtags ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java Changeset: abb39bc40bcc Author: mfang Date: 2013-08-13 15:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/abb39bc40bcc 8022856: 7u45 l10n resource file translation update Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties Changeset: 92c9a980216d Author: cl Date: 2013-08-15 22:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/92c9a980216d Added tag jdk7u45-b07 for changeset abb39bc40bcc ! .hgtags Changeset: 72295e1b27e6 Author: asaha Date: 2013-08-19 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/72295e1b27e6 Merge ! .hgtags Changeset: 16cf5bdca914 Author: cl Date: 2013-08-20 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/16cf5bdca914 Added tag jdk7u45-b08 for changeset 72295e1b27e6 ! .hgtags Changeset: e26f1ff1468a Author: joehw Date: 2013-08-19 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/e26f1ff1468a 8022682: Supporting XOM Reviewed-by: alanb, chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java + src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java Changeset: bb44f0ec198f Author: asaha Date: 2013-08-20 10:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/bb44f0ec198f Merge Changeset: 42b3cccfc39b Author: asaha Date: 2013-08-22 08:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/42b3cccfc39b Merge ! .hgtags Changeset: 255d92f5ed98 Author: asaha Date: 2013-08-26 08:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/255d92f5ed98 Merge ! .hgtags Changeset: ed0c89b23abe Author: cl Date: 2013-08-27 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/ed0c89b23abe Added tag jdk7u45-b09 for changeset 255d92f5ed98 ! .hgtags Changeset: 28a18e725bb3 Author: asaha Date: 2013-08-27 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/28a18e725bb3 Merge ! .hgtags Changeset: 4ccb23943a03 Author: cl Date: 2013-09-04 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/4ccb23943a03 Added tag jdk7u45-b10 for changeset 28a18e725bb3 ! .hgtags Changeset: 3d3b4da34d58 Author: asaha Date: 2013-09-04 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/3d3b4da34d58 Merge ! .hgtags Changeset: 2ac5c9749223 Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/2ac5c9749223 Added tag jdk7u45-b11 for changeset 3d3b4da34d58 ! .hgtags Changeset: 18a009fdfba2 Author: cl Date: 2013-09-18 02:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/18a009fdfba2 Added tag jdk7u45-b12 for changeset 2ac5c9749223 ! .hgtags Changeset: d577bae705f2 Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/d577bae705f2 Added tag jdk7u45-b13 for changeset 18a009fdfba2 ! .hgtags Changeset: daadec741c9b Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/daadec741c9b Added tag jdk7u45-b14 for changeset d577bae705f2 ! .hgtags Changeset: 0a8b95184728 Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0a8b95184728 Added tag jdk7u45-b15 for changeset daadec741c9b ! .hgtags Changeset: 89c3a3a27fb8 Author: asaha Date: 2013-10-01 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/89c3a3a27fb8 Merge ! .hgtags ! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java Changeset: 9e3f8ab9d17b Author: katleman Date: 2013-09-11 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/9e3f8ab9d17b Added tag jdk7u40-b61 for changeset c500d4ec41ff ! .hgtags Changeset: 99dcff4454b3 Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/99dcff4454b3 Added tag jdk7u40-b62 for changeset 9e3f8ab9d17b ! .hgtags Changeset: 0ed1050d54df Author: asaha Date: 2013-09-19 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0ed1050d54df Merge ! .hgtags Changeset: d30751811099 Author: asaha Date: 2013-09-27 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/d30751811099 Merge ! .hgtags Changeset: 2586d303503b Author: cl Date: 2013-10-03 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/2586d303503b Added tag jdk7u45-b16 for changeset 0a8b95184728 ! .hgtags Changeset: 4beb90ab48f7 Author: cl Date: 2013-10-07 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/4beb90ab48f7 Added tag jdk7u45-b17 for changeset 2586d303503b ! .hgtags Changeset: a456c78a50e2 Author: cl Date: 2013-10-08 09:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/a456c78a50e2 Added tag jdk7u45-b18 for changeset 4beb90ab48f7 ! .hgtags Changeset: 36a2c299f14a Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/36a2c299f14a Added tag jdk7u45-b30 for changeset a456c78a50e2 ! .hgtags Changeset: 3c34f244296e Author: asaha Date: 2013-10-08 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/3c34f244296e Merge ! .hgtags Changeset: 64a58670bd9c Author: asaha Date: 2013-10-08 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/64a58670bd9c Merge ! .hgtags Changeset: 056494e83d15 Author: cl Date: 2013-10-09 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/056494e83d15 Added tag jdk7u45-b31 for changeset 3c34f244296e ! .hgtags Changeset: 8da2a772ccbf Author: asaha Date: 2013-10-09 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/8da2a772ccbf Merge ! .hgtags Changeset: c2b11434288e Author: asaha Date: 2013-10-14 23:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/c2b11434288e Merge ! .hgtags From alejandro.murillo at oracle.com Wed Oct 23 15:31:00 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 22:31:00 +0000 Subject: hg: hsx/jdk7u/jaxws: 55 new changesets Message-ID: <20131023223301.61CCD626B7@hg.openjdk.java.net> Changeset: 4ee34d2cf2d8 Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/4ee34d2cf2d8 Added tag jdk7u40-b60 for changeset cbeef786ce48 ! .hgtags Changeset: d9a1af9117fb Author: mkos Date: 2013-10-08 16:00 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d9a1af9117fb 8025713: Syncing indendation/comment/copyright year differences with upstream projects Reviewed-by: coffeys, chegar ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceVisitor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/TempFiles.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/AssertionSet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/AssertionValidationProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/ComplexAssertion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/EffectiveAlternativeSelector.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/EffectivePolicyModifier.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/NestedPolicy.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/Policy.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyAssertion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyIntersector.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyMap.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyMapExtender.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyMapKey.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyMapKeyHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyMapMutator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyMerger.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicyScope.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/PolicySubject.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/SimpleAssertion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyLogger.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/RuntimePolicyUtilsException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/ServiceConfigurationError.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/ServiceFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/AssertionData.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/CompactModelGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/DefaultPolicyAssertionCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/ModelNode.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/NormalizedModelGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicyModelGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicyModelMarshaller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicyModelTranslator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicyModelUnmarshaller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicyReferenceData.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicySourceModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/PolicySourceModelContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/XmlPolicyModelMarshaller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/XmlPolicyModelUnmarshaller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ExternalAttachmentsUnmarshaller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/wspolicy/NamespaceVersion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/sourcemodel/wspolicy/XmlToken.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/spi/AbstractQNameValidator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/spi/AssertionCreationException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/spi/PolicyAssertionCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/spi/PolicyAssertionValidator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/spi/PrefixMapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/spi/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/subject/PolicyMapKeyConverter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/subject/WsdlBindingSubject.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/subject/package-info.java ! src/share/jaxws_classes/javax/xml/soap/AttachmentPart.java ! src/share/jaxws_classes/javax/xml/soap/Detail.java ! src/share/jaxws_classes/javax/xml/soap/DetailEntry.java ! src/share/jaxws_classes/javax/xml/soap/FactoryFinder.java ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java ! src/share/jaxws_classes/javax/xml/soap/MimeHeader.java ! src/share/jaxws_classes/javax/xml/soap/MimeHeaders.java ! src/share/jaxws_classes/javax/xml/soap/Name.java ! src/share/jaxws_classes/javax/xml/soap/Node.java ! src/share/jaxws_classes/javax/xml/soap/SAAJResult.java ! src/share/jaxws_classes/javax/xml/soap/SOAPBody.java ! src/share/jaxws_classes/javax/xml/soap/SOAPBodyElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnection.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConstants.java ! src/share/jaxws_classes/javax/xml/soap/SOAPElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPElementFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPEnvelope.java ! src/share/jaxws_classes/javax/xml/soap/SOAPException.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFault.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFaultElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPHeader.java ! src/share/jaxws_classes/javax/xml/soap/SOAPHeaderElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPMessage.java ! src/share/jaxws_classes/javax/xml/soap/SOAPPart.java ! src/share/jaxws_classes/javax/xml/soap/Text.java Changeset: acd6dd0d1c07 Author: coffeys Date: 2013-10-09 11:46 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/acd6dd0d1c07 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java Changeset: 501a6dedca75 Author: lana Date: 2013-10-09 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/501a6dedca75 Merge ! .hgtags Changeset: 49b754c39eac Author: asaha Date: 2013-06-20 21:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/49b754c39eac Merge ! .hgtags Changeset: e3ce837e7593 Author: asaha Date: 2013-06-21 21:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/e3ce837e7593 Merge ! .hgtags Changeset: 000becfcb945 Author: asaha Date: 2013-06-28 11:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/000becfcb945 Merge ! .hgtags Changeset: d832a74b195d Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d832a74b195d Added tag jdk7u45-b01 for changeset 000becfcb945 ! .hgtags Changeset: 817632baca26 Author: asaha Date: 2013-07-03 17:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/817632baca26 Merge ! .hgtags Changeset: 9c574d7d9d5f Author: katleman Date: 2013-07-09 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/9c574d7d9d5f Added tag jdk7u45-b02 for changeset 817632baca26 ! .hgtags Changeset: f65baba9400a Author: asaha Date: 2013-07-10 16:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/f65baba9400a Merge ! .hgtags Changeset: 1ab1aeff26f3 Author: cl Date: 2013-07-16 05:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/1ab1aeff26f3 Added tag jdk7u45-b03 for changeset f65baba9400a ! .hgtags Changeset: 80ff2468f520 Author: asaha Date: 2013-07-17 14:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/80ff2468f520 Merge ! .hgtags Changeset: d7a863258a7a Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d7a863258a7a Added tag jdk7u45-b04 for changeset 80ff2468f520 ! .hgtags Changeset: 48ff7ddecc26 Author: asaha Date: 2013-07-25 17:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/48ff7ddecc26 Merge ! .hgtags Changeset: d569f50b3a3f Author: asaha Date: 2013-07-29 11:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d569f50b3a3f Merge Changeset: 1128d3934b64 Author: asaha Date: 2013-07-31 23:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/1128d3934b64 Merge ! .hgtags Changeset: 59aa99dd5083 Author: asaha Date: 2013-08-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/59aa99dd5083 Added tag jdk7u45-b05 for changeset 1128d3934b64 ! .hgtags Changeset: c2cc41cf6055 Author: asaha Date: 2013-08-02 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c2cc41cf6055 Merge ! .hgtags Changeset: 76e34b113c91 Author: mkos Date: 2013-07-31 09:41 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/76e34b113c91 8017505: Better Client Service Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java + src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java + src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyUtils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/AbstractInstanceResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/server/MethodUtil.java Changeset: a9036e591b8e Author: mkos Date: 2013-08-01 15:41 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/a9036e591b8e 8022086: Fixing licence of newly added files Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/MethodUtil.java Changeset: 0b9d25854c59 Author: cl Date: 2013-08-02 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/0b9d25854c59 Added tag jdk7u45-b05 for changeset a9036e591b8e ! .hgtags Changeset: 5af79e819bc1 Author: asaha Date: 2013-08-05 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/5af79e819bc1 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: 1f63fafc7262 Author: asaha Date: 2013-08-05 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/1f63fafc7262 Merge ! .hgtags Changeset: 8da3d41d9469 Author: asaha Date: 2013-08-07 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/8da3d41d9469 Merge ! .hgtags Changeset: 5516a7f29f36 Author: cl Date: 2013-08-08 23:24 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/5516a7f29f36 Added tag jdk7u45-b06 for changeset 8da3d41d9469 ! .hgtags Changeset: 38f5b376c380 Author: asaha Date: 2013-08-12 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/38f5b376c380 Merge ! .hgtags Changeset: d6b6aafdeae2 Author: cl Date: 2013-08-15 22:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d6b6aafdeae2 Added tag jdk7u45-b07 for changeset 38f5b376c380 ! .hgtags Changeset: 86f3efd1edae Author: asaha Date: 2013-08-19 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/86f3efd1edae Merge ! .hgtags Changeset: e73af002b621 Author: cl Date: 2013-08-20 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/e73af002b621 Added tag jdk7u45-b08 for changeset 86f3efd1edae ! .hgtags Changeset: 4453cebb0d49 Author: asaha Date: 2013-08-22 08:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/4453cebb0d49 Merge ! .hgtags Changeset: ab835f7247e4 Author: asaha Date: 2013-08-26 08:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/ab835f7247e4 Merge ! .hgtags Changeset: 22ad90bdc501 Author: cl Date: 2013-08-27 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/22ad90bdc501 Added tag jdk7u45-b09 for changeset ab835f7247e4 ! .hgtags Changeset: bbd594e6cf45 Author: asaha Date: 2013-08-27 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/bbd594e6cf45 Merge ! .hgtags Changeset: 8890679c6f1f Author: cl Date: 2013-09-04 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/8890679c6f1f Added tag jdk7u45-b10 for changeset bbd594e6cf45 ! .hgtags Changeset: c01eab96821e Author: asaha Date: 2013-09-04 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c01eab96821e Merge ! .hgtags Changeset: 05f1274a8aa0 Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/05f1274a8aa0 Added tag jdk7u45-b11 for changeset c01eab96821e ! .hgtags Changeset: 3271849829b7 Author: cl Date: 2013-09-18 02:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/3271849829b7 Added tag jdk7u45-b12 for changeset 05f1274a8aa0 ! .hgtags Changeset: 842dd63be9c6 Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/842dd63be9c6 Added tag jdk7u45-b13 for changeset 3271849829b7 ! .hgtags Changeset: 93a3fb090be5 Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/93a3fb090be5 Added tag jdk7u45-b14 for changeset 842dd63be9c6 ! .hgtags Changeset: 5524cced32d3 Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/5524cced32d3 Added tag jdk7u45-b15 for changeset 93a3fb090be5 ! .hgtags Changeset: 97f3e821200f Author: asaha Date: 2013-10-01 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/97f3e821200f Merge ! .hgtags Changeset: b42a4cb742cf Author: katleman Date: 2013-09-11 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/b42a4cb742cf Added tag jdk7u40-b61 for changeset 4ee34d2cf2d8 ! .hgtags Changeset: d64adf18c8ae Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d64adf18c8ae Added tag jdk7u40-b62 for changeset b42a4cb742cf ! .hgtags Changeset: 41efeb4cecae Author: asaha Date: 2013-09-19 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/41efeb4cecae Merge ! .hgtags Changeset: 1703349383c3 Author: asaha Date: 2013-09-27 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/1703349383c3 Merge ! .hgtags Changeset: a8baf22b5972 Author: cl Date: 2013-10-03 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/a8baf22b5972 Added tag jdk7u45-b16 for changeset 5524cced32d3 ! .hgtags Changeset: 65b0f3ccdc8b Author: cl Date: 2013-10-07 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/65b0f3ccdc8b Added tag jdk7u45-b17 for changeset a8baf22b5972 ! .hgtags Changeset: c32c6a662d18 Author: cl Date: 2013-10-08 09:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c32c6a662d18 Added tag jdk7u45-b18 for changeset 65b0f3ccdc8b ! .hgtags Changeset: 9d95b39ca1d9 Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/9d95b39ca1d9 Added tag jdk7u45-b30 for changeset c32c6a662d18 ! .hgtags Changeset: 6802a1c098c4 Author: asaha Date: 2013-10-08 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/6802a1c098c4 Merge ! .hgtags Changeset: 5a6f745eb3c3 Author: asaha Date: 2013-10-08 14:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/5a6f745eb3c3 Merge ! .hgtags Changeset: e040abab3625 Author: cl Date: 2013-10-09 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/e040abab3625 Added tag jdk7u45-b31 for changeset 6802a1c098c4 ! .hgtags Changeset: 30fc11a1914e Author: asaha Date: 2013-10-09 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/30fc11a1914e Merge ! .hgtags Changeset: f675dfce1e61 Author: asaha Date: 2013-10-14 23:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/f675dfce1e61 Merge ! .hgtags From alejandro.murillo at oracle.com Wed Oct 23 15:26:03 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 22:26:03 +0000 Subject: hg: hsx/jdk7u: 52 new changesets Message-ID: <20131023222604.58788626B3@hg.openjdk.java.net> Changeset: 6359fa34199c Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/6359fa34199c Added tag jdk7u40-b60 for changeset dc1e099cd62d ! .hgtags Changeset: 0b78f51ceb4f Author: lana Date: 2013-10-09 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/0b78f51ceb4f Merge ! .hgtags Changeset: faabf9b83511 Author: asaha Date: 2013-06-20 21:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/faabf9b83511 Merge ! .hgtags Changeset: 9e21dad986e5 Author: asaha Date: 2013-06-21 21:56 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/9e21dad986e5 Merge ! .hgtags Changeset: e51f24701c60 Author: asaha Date: 2013-06-28 11:28 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/e51f24701c60 Merge ! .hgtags Changeset: a1761a968ddb Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/a1761a968ddb Added tag jdk7u45-b01 for changeset e51f24701c60 ! .hgtags Changeset: 07e41ff8674c Author: asaha Date: 2013-07-03 22:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/07e41ff8674c Merge ! .hgtags Changeset: 7d3cabf032a0 Author: katleman Date: 2013-07-09 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/7d3cabf032a0 Added tag jdk7u45-b02 for changeset 07e41ff8674c ! .hgtags Changeset: 23c983c352a1 Author: asaha Date: 2013-07-10 21:46 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/23c983c352a1 Merge ! .hgtags Changeset: e79d085b5666 Author: cl Date: 2013-07-16 05:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/e79d085b5666 Added tag jdk7u45-b03 for changeset 23c983c352a1 ! .hgtags Changeset: 19e4d8fbd509 Author: asaha Date: 2013-07-17 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/19e4d8fbd509 Merge ! .hgtags Changeset: 1018a8ab686d Author: asaha Date: 2013-07-22 22:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/1018a8ab686d 8020032: 7u fastdebug doesn't generate fastdebuginfo file Reviewed-by: tbell Contributed-by: tristan.yan at oracle.com ! Makefile Changeset: 1a7bcf5b173d Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/1a7bcf5b173d Added tag jdk7u45-b04 for changeset 1018a8ab686d ! .hgtags Changeset: 807cce4fa46a Author: asaha Date: 2013-07-25 15:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/807cce4fa46a Merge ! .hgtags ! Makefile Changeset: 5b1e3cb9af72 Author: asaha Date: 2013-07-29 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/5b1e3cb9af72 Merge Changeset: 22e0ca1fa645 Author: asaha Date: 2013-07-31 23:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/22e0ca1fa645 Merge ! .hgtags Changeset: 065564878326 Author: asaha Date: 2013-08-02 15:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/065564878326 Added tag jdk7u45-b05 for changeset 22e0ca1fa645 ! .hgtags Changeset: 9a08e6d6eb84 Author: asaha Date: 2013-08-02 15:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/9a08e6d6eb84 Merge ! .hgtags Changeset: a9e59d09051e Author: cl Date: 2013-08-02 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/a9e59d09051e Added tag jdk7u45-b05 for changeset 807cce4fa46a ! .hgtags Changeset: cf763e7e864c Author: asaha Date: 2013-08-05 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/cf763e7e864c 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: 3e965943d66c Author: asaha Date: 2013-08-05 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/3e965943d66c Merge ! .hgtags Changeset: 61343f60f25a Author: asaha Date: 2013-08-07 12:20 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/61343f60f25a Merge ! .hgtags Changeset: 9786d336c678 Author: cl Date: 2013-08-08 23:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/9786d336c678 Added tag jdk7u45-b06 for changeset 61343f60f25a ! .hgtags Changeset: 24088aaf3f68 Author: asaha Date: 2013-08-12 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/24088aaf3f68 Merge ! .hgtags Changeset: 71e94860715d Author: cl Date: 2013-08-15 22:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/71e94860715d Added tag jdk7u45-b07 for changeset 24088aaf3f68 ! .hgtags Changeset: 036425509e31 Author: asaha Date: 2013-08-19 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/036425509e31 Merge ! .hgtags Changeset: 6cc42e1e36b7 Author: cl Date: 2013-08-20 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/6cc42e1e36b7 Added tag jdk7u45-b08 for changeset 036425509e31 ! .hgtags Changeset: 247aff49b5cf Author: asaha Date: 2013-08-22 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/247aff49b5cf Merge ! .hgtags Changeset: b6af2c522a63 Author: asaha Date: 2013-08-26 08:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/b6af2c522a63 Merge ! .hgtags Changeset: 57f404092d1a Author: cl Date: 2013-08-27 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/57f404092d1a Added tag jdk7u45-b09 for changeset b6af2c522a63 ! .hgtags Changeset: 3fedb8c609a0 Author: asaha Date: 2013-08-27 15:13 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/3fedb8c609a0 Merge ! .hgtags Changeset: 2c473d04bc4b Author: cl Date: 2013-09-04 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/2c473d04bc4b Added tag jdk7u45-b10 for changeset 3fedb8c609a0 ! .hgtags Changeset: 142403d9f116 Author: asaha Date: 2013-09-04 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/142403d9f116 Merge ! .hgtags Changeset: a14018a5fa18 Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/a14018a5fa18 Added tag jdk7u45-b11 for changeset 142403d9f116 ! .hgtags Changeset: 4d38e9adeb81 Author: cl Date: 2013-09-18 02:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/4d38e9adeb81 Added tag jdk7u45-b12 for changeset a14018a5fa18 ! .hgtags Changeset: bab0456ba052 Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/bab0456ba052 Added tag jdk7u45-b13 for changeset 4d38e9adeb81 ! .hgtags Changeset: b4b258464902 Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/b4b258464902 Added tag jdk7u45-b14 for changeset bab0456ba052 ! .hgtags Changeset: f2479abad143 Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/f2479abad143 Added tag jdk7u45-b15 for changeset b4b258464902 ! .hgtags Changeset: afad34af2353 Author: asaha Date: 2013-10-01 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/afad34af2353 Merge ! .hgtags Changeset: a2605cf03226 Author: katleman Date: 2013-09-11 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/a2605cf03226 Added tag jdk7u40-b61 for changeset 6359fa34199c ! .hgtags Changeset: 8ae9ebf60745 Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/8ae9ebf60745 Added tag jdk7u40-b62 for changeset a2605cf03226 ! .hgtags Changeset: c782043adf1d Author: asaha Date: 2013-09-19 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/c782043adf1d Merge ! .hgtags Changeset: 93c0a4abb398 Author: asaha Date: 2013-09-27 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/93c0a4abb398 Merge ! .hgtags Changeset: 6fd67e0287a9 Author: cl Date: 2013-10-03 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/6fd67e0287a9 Added tag jdk7u45-b16 for changeset f2479abad143 ! .hgtags Changeset: f0cdb08a4624 Author: cl Date: 2013-10-07 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/f0cdb08a4624 Added tag jdk7u45-b17 for changeset 6fd67e0287a9 ! .hgtags Changeset: 82f1f76c4412 Author: cl Date: 2013-10-08 09:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/82f1f76c4412 Added tag jdk7u45-b18 for changeset f0cdb08a4624 ! .hgtags Changeset: 3a86bbf3f75a Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/3a86bbf3f75a Added tag jdk7u45-b30 for changeset 82f1f76c4412 ! .hgtags Changeset: f4373de4b75b Author: asaha Date: 2013-10-08 11:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/f4373de4b75b Merge ! .hgtags Changeset: d2dda463af3a Author: asaha Date: 2013-10-08 14:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/d2dda463af3a Merge ! .hgtags Changeset: b73c006b5d81 Author: cl Date: 2013-10-09 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/b73c006b5d81 Added tag jdk7u45-b31 for changeset f4373de4b75b ! .hgtags Changeset: cdb3d5ac96a6 Author: asaha Date: 2013-10-09 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/cdb3d5ac96a6 Merge ! .hgtags Changeset: f47b13738c41 Author: asaha Date: 2013-10-14 23:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/f47b13738c41 Merge ! .hgtags From alejandro.murillo at oracle.com Wed Oct 23 15:40:40 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 22:40:40 +0000 Subject: hg: hsx/jdk7u/jdk: 202 new changesets Message-ID: <20131023232227.F0BD3626B8@hg.openjdk.java.net> Changeset: c2a02bfda994 Author: weijun Date: 2013-08-09 11:41 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c2a02bfda994 8021788: JarInputStream doesn't provide certificates for some file under META-INF Reviewed-by: chegar, sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java Changeset: 2f890a506334 Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2f890a506334 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: 7e5de40af11a Author: dbuck Date: 2013-09-12 01:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7e5de40af11a 4673406: RFE: Java Printing: Provide a way to display win32 printer driver's dialog Summary: Displays the Windows DocumentProperties UI from the JDK's Swing print dialog. Reviewed-by: prr, 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: 1dfc719e1525 Author: sjiang Date: 2013-09-12 14:16 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1dfc719e1525 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: 8b6c41d76b9b Author: dmarkov Date: 2013-09-13 18:17 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8b6c41d76b9b 8024395: Improve fix for line break calculations Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/View.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: 5f14712b3dd5 Author: mcherkas Date: 2013-09-13 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5f14712b3dd5 8015601: [macosx] Test javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java fails on MacOS X Reviewed-by: alexp, alexsch ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: a0ae97463c58 Author: sjiang Date: 2013-09-16 17:17 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a0ae97463c58 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: cc055e12248d Author: bpb Date: 2013-09-17 13:06 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cc055e12248d 8024356: Double.parseDouble() is slow for long Strings Summary: Clamp nDigits to MAX_NDIGITS. Reviewed-by: bpb, drchase, shade Contributed-by: Dmitry Nadezhin ! src/share/classes/sun/misc/FloatingDecimal.java Changeset: 6af8b9ce93e1 Author: sjiang Date: 2013-09-18 12:53 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6af8b9ce93e1 8023954: MBean*Info.equals: throw NPE Reviewed-by: dfuchs, dholmes ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java + test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java Changeset: b3b0823d5501 Author: lana Date: 2013-09-18 13:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b3b0823d5501 Merge Changeset: 7b0aec4df3ca Author: kshefov Date: 2013-09-19 15:34 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7b0aec4df3ca 8006087: [TEST_BUG] The BACKSPACE key doesn't work and after pressing 'cancel' and 'DONE' button, the case pass automatically. Reviewed-by: serb, alexsch ! test/javax/swing/JFileChooser/4150029/bug4150029.html ! test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: 3ea038eab382 Author: kshefov Date: 2013-09-19 15:38 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3ea038eab382 8015597: [TEST_BUG] [macosx] Test closed/javax/swing/JMenuBar/4750590/bug4750590.java fails since JDK 8 b75 on MacOSX Reviewed-by: serb, alexsch + test/javax/swing/JMenuBar/4750590/bug4750590.java Changeset: 5db507b95002 Author: kshefov Date: 2013-09-19 15:44 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5db507b95002 7020060: [TEST_BUG] java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed Reviewed-by: anthony, serb ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: cb7d0128e069 Author: mcherkas Date: 2013-09-19 17:51 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cb7d0128e069 8016746: Test javax/swing/JTable/7068740/bug7068740.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JTable/7068740/bug7068740.java Changeset: bcea927e7d16 Author: sla Date: 2013-08-29 11:22 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/bcea927e7d16 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: ec0855d5b195 Author: coffeys Date: 2013-09-03 22:37 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ec0855d5b195 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar + test/com/sun/corba/transport/KeepAliveSockets.java Changeset: 9251ab32bcc4 Author: coffeys Date: 2013-09-23 11:08 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9251ab32bcc4 Merge Changeset: 168bd87376ea Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/168bd87376ea Added tag jdk7u40-b60 for changeset ed444a09a5fd ! .hgtags Changeset: 7d4324496f13 Author: coffeys Date: 2013-09-23 12:08 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7d4324496f13 Merge Changeset: d89c33d27e86 Author: alanb Date: 2013-09-18 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d89c33d27e86 8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx) Reviewed-by: alanb, coffeys Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java Changeset: 0ca8d6d46b74 Author: coffeys Date: 2013-09-23 14:18 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0ca8d6d46b74 Merge Changeset: b39302d414e4 Author: kshefov Date: 2013-09-23 17:58 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b39302d414e4 8015600: [TEST_BUG] [macosx] Test closed/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java Changeset: 3320bcbd2eaa Author: robm Date: 2013-09-23 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3320bcbd2eaa 7123493: (proxy) Proxy.getProxyClass doesn't scale under high load Reviewed-by: mchung ! src/share/classes/java/lang/reflect/Proxy.java + src/share/classes/java/lang/reflect/WeakCache.java Changeset: 64054ee415d5 Author: sla Date: 2013-09-23 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/64054ee415d5 8024027: Test sun/misc/IoTrace/IoTraceSocketReadWrite.java crashes VM Reviewed-by: alanb ! test/sun/misc/IoTrace/IoTraceAgent.java ! test/sun/misc/IoTrace/ioTraceTest.sh Changeset: d27628b9992e Author: igerasim Date: 2013-09-24 21:04 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d27628b9992e 8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN) Summary: the SetHandleInformation arguments list was fixed. Reviewed-by: alanb ! src/windows/native/java/lang/ProcessImpl_md.c Changeset: 393f837e828c Author: kshefov Date: 2013-09-25 10:56 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/393f837e828c 8015599: [TEST_BUG] [macosx] Test closed/javax/swing/Popup/TaskbarPositionTest.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/Popup/TaskbarPositionTest.java Changeset: 02c400654a20 Author: weijun Date: 2013-09-18 18:22 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/02c400654a20 8012615: Realm.getRealmsList returns realms list in wrong Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! test/sun/security/krb5/ParseCAPaths.java ! test/sun/security/krb5/krb5-capaths.conf Changeset: 4ed909846f6c Author: kshefov Date: 2013-09-26 12:23 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4ed909846f6c 8004032: [TEST_BUG] [macosx] There is no effect when double clicking on the Icon, after right clicking on the Icon and the Icon disappear Reviewed-by: anthony, serb + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java Changeset: 18e69c8d46c5 Author: weijun Date: 2013-09-27 15:25 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/18e69c8d46c5 8024861: Incomplete token triggers GSS-API NullPointerException Reviewed-by: mullan ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test/sun/security/jgss/spnego/MechTokenMissing.java Changeset: 5c608d2ad475 Author: kshefov Date: 2013-10-01 19:12 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5c608d2ad475 7124232: [TEST_BUG] [macosx] JSplitPane has wrong divider location Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: 074e2f411009 Author: kshefov Date: 2013-10-01 19:18 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/074e2f411009 8017180: [macosx] [TEST_BUG] alt-key doesn't work on macos for menu Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/javax/swing/JMenuItem/4171437/bug4171437.java + test/javax/swing/JPopupMenu/4458079/bug4458079.java Changeset: 2d35c307a7b4 Author: kshefov Date: 2013-10-01 19:23 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2d35c307a7b4 7124314: [TEST_BUG] [macosx] Aqua LAF: JTree doesn't select element by keyboards left and right keys Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JTree/4927934/bug4927934.java Changeset: 3471b2f6e23a Author: kshefov Date: 2013-10-01 19:26 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3471b2f6e23a 7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4193219/IconCoord.java Changeset: 91bb399c4eec Author: kshefov Date: 2013-10-01 19:31 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/91bb399c4eec 7124320: [TEST_BUG] [macosx] JComboBox doesn't change selection on mouse over Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JComboBox/6236162/bug6236162.java Changeset: 993aa7f7d37b Author: kshefov Date: 2013-10-01 19:34 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/993aa7f7d37b 7133154: [TEST_BUG] [macosx] closed/javax/swing/JInternalFrame/4251301/bug4251301.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4251301/bug4251301.java Changeset: 9932ee9dfed2 Author: aefimov Date: 2013-10-01 17:15 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9932ee9dfed2 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea + test/javax/xml/jaxp/parsers/8024707/TestFunc.java + test/javax/xml/jaxp/parsers/8024707/XSLT.java + test/javax/xml/jaxp/parsers/8024707/in.xml + test/javax/xml/jaxp/parsers/8024707/test.xsl Changeset: ec625df0c6f7 Author: alitvinov Date: 2013-10-02 11:30 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ec625df0c6f7 8025145: [macosx]: java 7 does not recognize tiff image on clipboard Reviewed-by: anthony, serb Contributed-by: anton.nashatyrev at oracle.com ! src/macosx/lib/flavormap.properties Changeset: 6f819a9bc652 Author: dmarkov Date: 2013-10-03 12:14 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6f819a9bc652 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, alexp ! make/sun/awt/Makefile + src/macosx/classes/sun/awt/resources/awtosx.properties ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/AWTAccessor.java + test/java/awt/Toolkit/ToolkitPropertyTest/bug7129133.java Changeset: d54b3da964d7 Author: vkempik Date: 2013-09-25 17:35 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d54b3da964d7 6889597: TEST_BUG: javax/management/remote/mandatory/URLTest.java test should be updated in jdk7 Workspace Reviewed-by: alanb ! test/javax/management/remote/mandatory/URLTest.java Changeset: 94098d8ee492 Author: mcherkas Date: 2013-10-03 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/94098d8ee492 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: alexp, malenkov ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 85a94425d233 Author: dsamersoff Date: 2013-10-03 23:24 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/85a94425d233 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Summary: There's no guarantee that the java process has executed far enough to be found by jps when we try to obtain it's pid. Reviewed-by: sla ! test/sun/management/jdp/JdpTest.sh Changeset: 1744fc1a2228 Author: khazra Date: 2012-05-29 13:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1744fc1a2228 7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c should return a value Summary: Use CHECK_NULL_RETURN instead of CHECK_NULL Reviewed-by: alanb ! src/solaris/native/java/net/net_util_md.c Changeset: d419d3b5bbfa Author: coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d419d3b5bbfa 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java Changeset: e7aabb7d4fe6 Author: coffeys Date: 2013-10-04 16:27 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e7aabb7d4fe6 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar + test/javax/xml/ws/clientjar/TestService.java + test/javax/xml/ws/clientjar/TestWsImport.java Changeset: 0e06acc37b64 Author: dxu Date: 2013-10-09 14:22 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0e06acc37b64 8025128: File.createTempFile fails if prefix is absolute path Summary: Use only the file name from the supplied prefix for backward compatibility Reviewed-by: alanb, chegar ! src/share/classes/java/io/File.java ! test/java/io/File/createTempFile/SpecialTempFile.java Changeset: 1956afd10fc7 Author: lana Date: 2013-10-09 14:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1956afd10fc7 Merge ! .hgtags Changeset: 85226f84bc29 Author: jbachorik Date: 2013-04-23 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/85226f84bc29 8011081: Improve jhat Summary: Properly escape HTML output Reviewed-by: alanb, mschoene, sundar ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java Changeset: 84c4ba2a1794 Author: asaha Date: 2013-04-23 22:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/84c4ba2a1794 Merge Changeset: b20992035fb7 Author: bae Date: 2013-04-24 15:23 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b20992035fb7 8012438: Better image validation Reviewed-by: mschoene, prr, vadim ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/Raster.java ! src/share/classes/sun/awt/image/ByteBandedRaster.java ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/BytePackedRaster.java ! src/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/share/classes/sun/awt/image/ShortBandedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: f181f42bdbf8 Author: prr Date: 2013-04-25 21:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f181f42bdbf8 8012617: ArrayIndexOutOfBoundsException with some fonts using LineBreakMeasurer Reviewed-by: bae, srl ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SunLayoutEngine.cpp + test/java/awt/font/LineBreakMeasurer/AllFontsLBM.java Changeset: e5046690c014 Author: bae Date: 2013-04-26 09:30 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e5046690c014 8012601: Better validation of image layouts Reviewed-by: mschoene, prr, vadim ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java Changeset: c282e264ab00 Author: alexsch Date: 2013-04-29 16:46 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c282e264ab00 8012330: [macosx] Sometimes the applet showing the modal dialog itself loses the ability to gain focus Reviewed-by: serb, ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: 272c3851c0f2 Author: bae Date: 2013-04-30 04:20 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/272c3851c0f2 8012597: Better image channel verification Reviewed-by: ahgross, vadim, prr ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: c4b57ff3d99e Author: mcherkas Date: 2013-02-12 16:11 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c4b57ff3d99e 8005932: Java 7 on mac os x only provides text clipboard formats Reviewed-by: alexp, denis ! src/macosx/lib/flavormap.properties + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java Changeset: ba16240d53b8 Author: asaha Date: 2013-04-30 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ba16240d53b8 Merge Changeset: cea62063a49e Author: dfuchs Date: 2013-05-01 00:49 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cea62063a49e 8012243: about 30% regression on specjvm2008.serial on 7u25 comparing 7u21 Reviewed-by: alanb, skoivu, smarks, mchung ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/ObjectStreamField.java Changeset: 3095097842e1 Author: coffeys Date: 2013-05-01 21:02 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3095097842e1 8013196: TimeZone.getDefault() throws NPE due to sun.awt.AppContext.getAppContext() Reviewed-by: mchung, okutsu ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: 5872319f9adf Author: mullan Date: 2013-05-01 17:19 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5872319f9adf 8008744: Rework part of fix for JDK-6741606 Reviewed-by: xuelei, ahgross + src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java + src/share/classes/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java Changeset: 9fb20c70c89d Author: mullan Date: 2013-05-01 17:25 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9fb20c70c89d Merge Changeset: 63bf3f0ba262 Author: leonidr Date: 2013-05-06 16:30 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/63bf3f0ba262 8012933: Test closed/java/awt/Dialog/DialogAnotherThread/JaWSTest.java fails since jdk 7u25 b07 Summary: Do not mark context as disposed until we've posted all the events Reviewed-by: art ! src/share/classes/sun/awt/AppContext.java + test/sun/awt/AppContext/8012933/Test8012933.java Changeset: b09f318baa8b Author: ksrini Date: 2013-05-07 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b09f318baa8b 8013506: Better Pack200 data handling Reviewed-by: jrose, kizune, mschoene ! src/share/native/com/sun/java/util/jar/pack/zip.cpp Changeset: 9a7df62c2e7f Author: jgish Date: 2013-04-19 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9a7df62c2e7f 8010939: Deadlock in LogManager Summary: re-order locks to avoid deadlock Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/DrainFindDeadlockTest.java Changeset: 3abe390615e3 Author: jchen Date: 2013-05-09 11:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3abe390615e3 8013510: Augment image writing code Reviewed-by: bae, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: c2698b462a49 Author: mullan Date: 2013-05-10 16:28 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c2698b462a49 8010714: XML DSig API allows a RetrievalMethod to reference another RetrievalMethod Reviewed-by: xuelei, hawtin ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java Changeset: 2cc8437acff9 Author: mullan Date: 2013-05-10 16:36 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2cc8437acff9 Merge Changeset: e4305995090b Author: vadim Date: 2013-05-13 13:24 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e4305995090b 8013514: Improve stability of cmap class Reviewed-by: mschoene, prr, bae ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/TrueTypeFont.java Changeset: 6f7486c48aa3 Author: uta Date: 2013-05-13 20:09 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6f7486c48aa3 8014046: (process) Runtime.exec(String) fails if command contains spaces [win] Reviewed-by: alanb ! src/share/classes/java/lang/ProcessBuilder.java ! src/windows/classes/java/lang/ProcessImpl.java + test/java/lang/Runtime/exec/ExecCommand.java Changeset: 6edc9e3e8613 Author: xuelei Date: 2013-05-13 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6edc9e3e8613 8014281: Better checking of XML signature Summary: also reviewed by Andrew Gross and Christophe Ravel Reviewed-by: mullan ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java Changeset: f60425bc184b Author: mchung Date: 2013-05-14 08:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f60425bc184b 8010727: WLS fails to add a logger with "" in its own LogManager subclass instance Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/LogManagerInstanceTest.java Changeset: b3b8c06cefff Author: serb Date: 2013-05-14 20:22 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b3b8c06cefff 8014423: [macosx] The scrollbar's block increment performs incorrectly Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java Changeset: 692f9aea4365 Author: bae Date: 2013-05-14 21:05 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/692f9aea4365 8014427: REGRESSION: closed/javax/imageio/plugins/bmp/Write3ByteBgrTest.java fails since 7u25 b09 Reviewed-by: prr, vadim ! src/share/classes/java/awt/image/Raster.java Changeset: 419e6025e324 Author: jgish Date: 2013-05-14 15:42 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/419e6025e324 8013380: Removal of stack walk to find resource bundle breaks Glassfish startup Summary: Use caller's classloader to load resource as an alternative to thread context classloader and system classloader Reviewed-by: mchung, alanb ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/bundlesearch/IndirectlyLoadABundle.java - test/java/util/logging/bundlesearch/LoadItUp.java + test/java/util/logging/bundlesearch/LoadItUp1.java + test/java/util/logging/bundlesearch/LoadItUp2.java + test/java/util/logging/bundlesearch/LoadItUp2Invoker.java ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java + test/java/util/logging/bundlesearch/TwiceIndirectlyLoadABundle.java + test/java/util/logging/bundlesearch/resources/CallerSearchableResource_en.properties Changeset: 694c686c0e8a Author: asaha Date: 2013-05-15 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/694c686c0e8a Merge - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 5bcbe71b551d Author: bae Date: 2013-05-17 16:07 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5bcbe71b551d 8014205: Most of the Swing dialogs are blank on one win7 MUI Reviewed-by: prr, vadim ! src/share/classes/java/awt/image/BufferedImage.java Changeset: 26edfc8182bb Author: bae Date: 2013-05-17 16:47 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/26edfc8182bb 8014093: Improve parsing of images Reviewed-by: prr ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: a6e52401ab9a Author: dmeetry Date: 2013-05-17 19:59 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a6e52401ab9a 8014676: Java debugger may fail to run Summary: The problem is observed when the binaries for windows are placed under a path which contains a space Reviewed-by: alanb Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java Changeset: 3c60dc9b19b9 Author: mchung Date: 2013-05-17 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3c60dc9b19b9 8014745: Provide a switch to allow stack walk search of resource bundle Reviewed-by: alanb, jgish ! make/java/java/mapfile-vers ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/native/sun/reflect/Reflection.c ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java Changeset: 3db0c3b7e851 Author: malenkov Date: 2013-05-20 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3db0c3b7e851 8012071: Better Building of Beans Reviewed-by: art, skoivu ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/MetaData.java Changeset: 12dfdb90cc90 Author: leonidr Date: 2013-05-20 18:51 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/12dfdb90cc90 8014718: Netbeans IDE begins to throw a lot exceptions since 7u25 b10 Summary: Removed logging from SunToolkit Reviewed-by: art ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 0783b9189e71 Author: bae Date: 2013-05-21 13:56 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0783b9189e71 8014102: Improve image conversion Reviewed-by: prr ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 2790e9ace697 Author: alexsch Date: 2013-05-21 19:04 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2790e9ace697 8013744: Better tabling for AWT Reviewed-by: art, malenkov, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 10cd25a8c020 Author: asaha Date: 2013-05-21 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/10cd25a8c020 Merge ! test/java/util/logging/bundlesearch/LoadItUp1.java Changeset: 65b07e0a2f36 Author: asaha Date: 2013-05-22 22:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/65b07e0a2f36 Merge Changeset: b6ab933f06e0 Author: malenkov Date: 2013-05-31 20:43 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b6ab933f06e0 8012277: Improve AWT DataFlavor Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 0b84d3b434c2 Author: weijun Date: 2013-05-08 09:21 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0b84d3b434c2 8014341: Better service from Kerberos servers Summary: read incoming data safely and take care of null return value Reviewed-by: valeriep, ahgross ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java Changeset: 49b7500a2ca6 Author: asaha Date: 2013-06-04 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/49b7500a2ca6 Merge Changeset: 2d070be9a313 Author: coffeys Date: 2013-06-05 18:39 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2d070be9a313 8015965: (process) Typo in name of property to allow ambiguous commands Reviewed-by: alanb ! src/windows/classes/java/lang/ProcessImpl.java ! test/java/lang/Runtime/exec/ExecCommand.java Changeset: cbd812992676 Author: asaha Date: 2013-06-06 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cbd812992676 Merge Changeset: 5c09550dfc12 Author: asaha Date: 2013-06-12 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5c09550dfc12 Merge Changeset: 18479f069dab Author: asaha Date: 2013-06-12 09:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/18479f069dab Merge Changeset: 600107f4664d Author: weijun Date: 2013-06-13 10:21 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/600107f4664d 8013739: Better LDAP resource management Reviewed-by: ahgross, mchung, xuelei ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: e074eb78c8fd Author: weijun Date: 2013-06-13 10:31 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e074eb78c8fd 8015731: Subject java.security.auth.subject to improvements Reviewed-by: skoivu, mullan ! src/share/classes/javax/security/auth/Subject.java Changeset: 7bb0a656747b Author: asaha Date: 2013-06-12 21:49 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7bb0a656747b Merge Changeset: 7c6cf3cf585f Author: jchen Date: 2013-06-13 12:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7c6cf3cf585f 8014098: Better profile validation Reviewed-by: bae, prr ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c Changeset: ff9410fce108 Author: msheppar Date: 2013-06-14 17:28 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ff9410fce108 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! make/com/sun/jmx/Makefile ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java Changeset: e6e9f510b6f2 Author: asaha Date: 2013-06-19 21:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e6e9f510b6f2 Merge Changeset: ec7788ebe005 Author: jbachorik Date: 2013-06-20 08:51 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ec7788ebe005 8014085: Better serialization support in JMX classes Reviewed-by: alanb, dfuchs, skoivu ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/JMXPrincipal.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java Changeset: 0bf72cc56dc3 Author: erikj Date: 2013-06-24 10:32 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0bf72cc56dc3 8012147: Improve tool support Summary: Adding libjli to jdk lib dir and removing now redundant rpath entries from executables Reviewed-by: alanb, dholmes, ksrini, ahgross ! make/common/Program.gmk ! make/common/Release.gmk ! test/Makefile Changeset: 9b734892dae6 Author: asaha Date: 2013-06-21 19:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9b734892dae6 Merge ! .hgtags - make/com/sun/servicetag/Makefile - make/sun/rmi/rmi/mapfile-vers - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html ! src/share/classes/java/beans/MetaData.java - src/share/classes/java/beans/ReflectionUtils.java - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/sun/swing/SwingUtilities2.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java - src/share/lib/security/java.security - src/share/native/sun/rmi/server/MarshalInputStream.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java - test/java/io/File/isDirectory/Applet.html - test/java/io/Serializable/accessConstants/AccessConstants.java - test/sun/net/www/messageheader/0 - test/sun/net/www/messageheader/1 - test/sun/net/www/messageheader/2 - test/sun/net/www/messageheader/3 - test/sun/net/www/messageheader/4 - test/sun/net/www/messageheader/5 - test/sun/net/www/messageheader/6 - test/sun/net/www/messageheader/HTest.java - test/sun/nio/cs/OLD/TestX11CS.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: 434ca5ec5a3b Author: asaha Date: 2013-06-21 21:58 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/434ca5ec5a3b Merge ! .hgtags Changeset: ba861ea65297 Author: asaha Date: 2013-06-24 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ba861ea65297 Merge Changeset: 2cc729dda2f8 Author: asaha Date: 2013-06-25 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2cc729dda2f8 Merge - make/com/sun/servicetag/Makefile ! make/common/Program.gmk ! make/common/Release.gmk - make/sun/rmi/rmi/mapfile-vers - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - src/share/classes/java/beans/ReflectionUtils.java - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java - src/share/lib/security/java.security - src/share/native/sun/rmi/server/MarshalInputStream.c ! test/Makefile - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java - test/java/io/File/isDirectory/Applet.html - test/java/io/Serializable/accessConstants/AccessConstants.java - test/sun/net/www/messageheader/0 - test/sun/net/www/messageheader/1 - test/sun/net/www/messageheader/2 - test/sun/net/www/messageheader/3 - test/sun/net/www/messageheader/4 - test/sun/net/www/messageheader/5 - test/sun/net/www/messageheader/6 - test/sun/net/www/messageheader/HTest.java - test/sun/nio/cs/OLD/TestX11CS.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: 517a47e66573 Author: asaha Date: 2013-06-28 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/517a47e66573 Merge ! .hgtags ! src/windows/classes/java/lang/ProcessImpl.java ! test/java/lang/Runtime/exec/ExecCommand.java Changeset: b06abd965701 Author: bae Date: 2013-07-01 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b06abd965701 8017287: Better resource disposal Reviewed-by: vadim ! src/share/classes/sun/java2d/Disposer.java Changeset: 4a9ced03945a Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4a9ced03945a Added tag jdk7u45-b01 for changeset b06abd965701 ! .hgtags Changeset: 95eeca6dc691 Author: michaelm Date: 2013-07-03 17:54 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/95eeca6dc691 8015743: Address internet addresses Summary: moved Inet6Address fields to holder class Reviewed-by: chegar, alanb, skoivu, khazra ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! test/java/net/Inet6Address/serialize/Serialize.java Changeset: 4fc1467017ea Author: prr Date: 2013-07-03 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4fc1467017ea 8015144: Performance regression in ICU OpenType Layout library Reviewed-by: srl, jgodinez ! make/sun/font/Makefile ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp Changeset: bcd02823f5f5 Author: asaha Date: 2013-07-03 17:43 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/bcd02823f5f5 Merge ! .hgtags ! make/common/Release.gmk Changeset: 0c8d67d9e6d3 Author: ascarpino Date: 2013-07-03 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0c8d67d9e6d3 8011071: Better crypto provider handling Reviewed-by: hawtin, valeriep ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/provider/DSAPrivateKey.java ! src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java Changeset: d23a877da2d5 Author: dsamersoff Date: 2013-07-08 14:34 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d23a877da2d5 8008589: Better MBean permission validation Summary: Better MBean permission validation Reviewed-by: skoivu, dfuchs, mchung, sjiang ! src/share/classes/javax/management/MBeanTrustPermission.java Changeset: 34296e49d95f Author: katleman Date: 2013-07-09 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/34296e49d95f Added tag jdk7u45-b02 for changeset d23a877da2d5 ! .hgtags Changeset: 57f1db230d23 Author: asaha Date: 2013-07-10 16:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/57f1db230d23 Merge ! .hgtags Changeset: fe6f6165412a Author: msheppar Date: 2013-07-11 23:16 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/fe6f6165412a 8020085: Linux ARM build failure for 7u45 Summary: Amend jdk/make/com/sun/jmx/Makefile to fix 7u45 build failure Reviewed-by: coffeys, dholmes ! make/com/sun/jmx/Makefile Changeset: 390752a9e4ee Author: smarks Date: 2013-07-10 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/390752a9e4ee 8014987: Augment serialization handling Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java Changeset: c378b877f5b6 Author: mchung Date: 2013-07-15 03:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c378b877f5b6 8017291: Cast Proxies Aside Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ClassLoader.java Changeset: 328d974d2eb8 Author: michaelm Date: 2013-07-15 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/328d974d2eb8 8019969: nioNetworkChannelInet6/SetOptionGetOptionTestInet6 test case crashes Reviewed-by: chegar ! src/windows/native/java/net/net_util_md.c Changeset: a56eb4f80123 Author: jfranck Date: 2013-07-15 18:41 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a56eb4f80123 8014349: (cl) Class.getDeclaredClass problematic in some class loader configurations Reviewed-by: mchung, ahgross, darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/native/java/lang/Class.c Changeset: 0b2f8e7cfadd Author: cl Date: 2013-07-16 05:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0b2f8e7cfadd Added tag jdk7u45-b03 for changeset a56eb4f80123 ! .hgtags Changeset: 1d42f8941555 Author: malenkov Date: 2013-07-16 21:00 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1d42f8941555 8019617: Better view of objects Reviewed-by: art, skoivu ! src/share/classes/javax/swing/text/html/ObjectView.java Changeset: c919b499eb96 Author: sundar Date: 2013-07-16 23:02 +0530 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c919b499eb96 8017300: Improve Interface Implementation Reviewed-by: ahgross, jlaskey, mchung ! src/share/classes/com/sun/script/util/InterfaceImplementor.java ! 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: 269dc6aa6b62 Author: sjiang Date: 2013-07-18 10:12 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/269dc6aa6b62 8014534: Better profiling support Summary: Validation of parameters Reviewed-by: sspitsyn, skoivu, mchung ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c Changeset: 3ebfb90320ef Author: mchung Date: 2013-07-18 17:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3ebfb90320ef 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 54bd9675a80b Author: okutsu Date: 2013-07-19 15:32 +0900 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/54bd9675a80b 8006900: Add new date/time capability Reviewed-by: mchung, hawtin ! src/share/classes/java/util/TimeZone.java Changeset: 0f7896059207 Author: jbachorik Date: 2013-07-19 16:29 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0f7896059207 8019584: javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Reviewed-by: mchung, sjiang, dfuchs, ahgross ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java Changeset: 447531e39bad Author: jchen Date: 2013-07-22 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/447531e39bad 8020293: JVM crash Reviewed-by: prr, jgodinez ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ba3da584814b Author: asaha Date: 2013-07-22 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ba3da584814b Merge ! .hgtags ! 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: 01b9e1ec3b9b Author: asaha Date: 2013-07-22 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/01b9e1ec3b9b Merge Changeset: 702c8d83dd8c Author: sgabdura Date: 2013-07-23 10:01 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/702c8d83dd8c 8016357: Update hotspot diagnostic class Summary: Add security check to HotSpotDiagnostic.dumpHeap Reviewed-by: fparain, sla, ahgross ! make/java/management/mapfile-vers ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c Changeset: aac9848719a9 Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/aac9848719a9 Added tag jdk7u45-b04 for changeset 702c8d83dd8c ! .hgtags Changeset: 31416e6673db Author: asaha Date: 2013-07-25 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/31416e6673db Merge ! .hgtags ! src/share/classes/javax/swing/JTable.java Changeset: 6c81a895ac96 Author: jbachorik Date: 2013-07-29 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6c81a895ac96 8021577: JCK test api/javax_management/jmx_serial/modelmbean/ModelMBeanNotificationInfo/serial/index.html#Input has failed since jdk 7u45 b01 Reviewed-by: alanb, dfuchs, ahgross ! src/share/classes/javax/management/MBeanNotificationInfo.java Changeset: a7758faab30d Author: mullan Date: 2013-07-30 17:20 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a7758faab30d 8021290: Better signature validation Reviewed-by: xuelei, ahgross ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java Changeset: c32b22b37cf2 Author: mullan Date: 2013-07-30 17:27 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c32b22b37cf2 Merge Changeset: 4c6eb1390566 Author: asaha Date: 2013-07-29 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4c6eb1390566 Merge ! src/share/native/java/net/net_util.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 5acb9e506858 Author: asaha Date: 2013-07-30 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5acb9e506858 8021899: Re-adjust fix of # 8020498 in 7u45 after mergeing 7u40 Reviewed-by: chegar ! src/share/native/java/net/net_util.c Changeset: 0547d262d086 Author: asaha Date: 2013-07-31 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0547d262d086 Merge Changeset: a70540e8a5e9 Author: asaha Date: 2013-07-31 23:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a70540e8a5e9 Merge ! .hgtags Changeset: feec296936c9 Author: asaha Date: 2013-08-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/feec296936c9 Added tag jdk7u45-b05 for changeset a70540e8a5e9 ! .hgtags Changeset: a98bcad1f6f0 Author: asaha Date: 2013-08-02 22:27 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a98bcad1f6f0 Merge ! .hgtags ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 81ea60e97a31 Author: asaha Date: 2013-08-07 12:04 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/81ea60e97a31 Merge Changeset: 1a2e92866dba Author: asaha Date: 2013-08-07 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1a2e92866dba Merge ! .hgtags Changeset: dd5a285302c7 Author: sjiang Date: 2013-08-06 16:04 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/dd5a285302c7 8019292: Better Attribute Value Exceptions Reviewed-by: dfuchs, dholmes, ahgross ! src/share/classes/javax/management/BadAttributeValueExpException.java Changeset: cd066f29f36f Author: malenkov Date: 2013-08-07 16:51 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cd066f29f36f 8021969: The index_AccessAllowed jnlp can not load successfully with exception thrown in the log. Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 94533c087a66 Author: serb Date: 2013-08-04 16:32 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/94533c087a66 8021282: Better recycling of object instances Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaUtils.java Changeset: 0967554fe14c Author: naoto Date: 2013-08-01 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0967554fe14c 8021286: Improve MacOS resourcing Reviewed-by: okutsu - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/Makefile ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m Changeset: 362a52dcca99 Author: naoto Date: 2013-08-01 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/362a52dcca99 8021287: Improve MacOS resourcing Reviewed-by: okutsu - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/Makefile ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m Changeset: ce1e3b62b74e Author: cl Date: 2013-08-02 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ce1e3b62b74e Added tag jdk7u45-b05 for changeset 362a52dcca99 ! .hgtags Changeset: 5787121ada85 Author: serb Date: 2013-08-04 16:32 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5787121ada85 8021282: Better recycling of object instances Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaUtils.java Changeset: f13f5edb1e09 Author: asaha Date: 2013-08-05 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f13f5edb1e09 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: cb81fafffb8d Author: asaha Date: 2013-08-05 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cb81fafffb8d Merge ! .hgtags Changeset: 5d9bbfa0096f Author: sjiang Date: 2013-08-06 16:04 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5d9bbfa0096f 8019292: Better Attribute Value Exceptions Reviewed-by: dfuchs, dholmes, ahgross ! src/share/classes/javax/management/BadAttributeValueExpException.java Changeset: 675b9971b25b Author: asaha Date: 2013-08-06 07:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/675b9971b25b Merge Changeset: 480b85c53071 Author: malenkov Date: 2013-08-07 16:51 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/480b85c53071 8021969: The index_AccessAllowed jnlp can not load successfully with exception thrown in the log. Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: f39399baf367 Author: asaha Date: 2013-08-07 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f39399baf367 Merge ! .hgtags Changeset: 06345027b0f7 Author: cl Date: 2013-08-08 23:24 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/06345027b0f7 Added tag jdk7u45-b06 for changeset f39399baf367 ! .hgtags Changeset: 1b96fdac9e9c Author: asaha Date: 2013-08-12 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1b96fdac9e9c Merge ! .hgtags Changeset: e87be44883ad Author: jbachorik Date: 2013-08-08 19:16 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e87be44883ad 8021360: object not exported" on start of JMXConnectorServer for RMI-IIOP protocol with security manager Reviewed-by: alanb, ahgross, smarks, coffeys ! src/share/classes/com/sun/jmx/remote/protocol/iiop/IIOPProxyImpl.java Changeset: 23291ff6e7a7 Author: asaha Date: 2013-08-09 07:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/23291ff6e7a7 Merge Changeset: ff72fefa5b8c Author: serb Date: 2013-08-12 21:33 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ff72fefa5b8c 8021275: Better screening for ScreenMenu Reviewed-by: art ! src/macosx/classes/com/apple/laf/ScreenMenu.java Changeset: a448d16d000b Author: asaha Date: 2013-08-12 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a448d16d000b Merge Changeset: 4053352342e6 Author: twisti Date: 2013-08-12 14:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4053352342e6 8022066: Evaluation of method reference to signature polymorphic method crashes VM Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/MethodHandleConstants.java Changeset: a35d4a4ebcfa Author: ksrini Date: 2013-08-14 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a35d4a4ebcfa 8021355: REGRESSION: Five closed/java/awt/SplashScreen tests fail since 7u45 b01 on Linux, Solaris Reviewed-by: dholmes, anthony, ahgross, erikj ! src/solaris/bin/java_md_solinux.c Changeset: 868c36150f11 Author: cl Date: 2013-08-15 22:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/868c36150f11 Added tag jdk7u45-b07 for changeset a35d4a4ebcfa ! .hgtags Changeset: ffe487772a54 Author: weijun Date: 2013-08-17 06:51 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ffe487772a54 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: 12149d2a0a72 Author: asaha Date: 2013-08-19 12:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/12149d2a0a72 Merge ! .hgtags Changeset: 2f01847eb953 Author: erikj Date: 2013-08-19 17:51 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2f01847eb953 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/bridge/Jabswitch/Makefile Changeset: 8c29637bb097 Author: cl Date: 2013-08-20 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8c29637bb097 Added tag jdk7u45-b08 for changeset 2f01847eb953 ! .hgtags Changeset: c33c9d0cbf16 Author: asaha Date: 2013-08-22 08:43 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c33c9d0cbf16 Merge ! .hgtags Changeset: 8028c94526f8 Author: chegar Date: 2013-08-09 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8028c94526f8 8022661: InetAddress.writeObject() performs flush() on object output stream Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java Changeset: 6e2313d45f0c Author: asaha Date: 2013-08-26 08:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6e2313d45f0c Merge ! .hgtags Changeset: 78d2c049f56e Author: cl Date: 2013-08-27 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/78d2c049f56e Added tag jdk7u45-b09 for changeset 6e2313d45f0c ! .hgtags Changeset: d4506b816f63 Author: asaha Date: 2013-08-27 15:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d4506b816f63 Merge ! .hgtags Changeset: afbc9a752e50 Author: cl Date: 2013-09-04 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/afbc9a752e50 Added tag jdk7u45-b10 for changeset d4506b816f63 ! .hgtags Changeset: f1969be9db78 Author: asaha Date: 2013-09-04 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f1969be9db78 Merge ! .hgtags Changeset: e045f6a3ad1d Author: coffeys Date: 2013-09-06 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e045f6a3ad1d 8023964: java/io/IOException/LastErrorString.java should be @ignore-d Reviewed-by: alanb ! test/java/io/IOException/LastErrorString.java Changeset: 5030eb1a2797 Author: asaha Date: 2013-09-06 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5030eb1a2797 Merge Changeset: ee87452ba9e2 Author: sherman Date: 2013-09-10 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ee87452ba9e2 6614237: missing codepage Cp290 at java runtime Summary: to add cp290 and cp300 Reviewed-by: alanb, coffeys + make/tools/CharsetMapping/IBM290.c2b + make/tools/CharsetMapping/IBM290.map ! make/tools/CharsetMapping/extsbcs ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/IBM300.java Changeset: 8b32ded99544 Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8b32ded99544 Added tag jdk7u45-b11 for changeset ee87452ba9e2 ! .hgtags Changeset: 043d8d63ef38 Author: sherman Date: 2013-09-12 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/043d8d63ef38 8024668: api/java_nio/charset/Charset/index.html#Methods JCK-runtime test fails with 7u45 b11 Summary: to add IBM290 into make/sun/nio/cs/FILES_java.gmk Reviewed-by: alanb, coffeys ! make/sun/nio/cs/FILES_java.gmk Changeset: d5e393a55e6a Author: bae Date: 2013-09-13 19:19 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d5e393a55e6a 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: 05f1f12d7ddb Author: cl Date: 2013-09-18 02:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/05f1f12d7ddb Added tag jdk7u45-b12 for changeset d5e393a55e6a ! .hgtags Changeset: a8f923119eb1 Author: erikj Date: 2013-09-19 13:32 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a8f923119eb1 8023771: when USER_RELEASE_SUFFIX is set in order to add a string to java -version, build number in the bundles names should not be changed to b00 Reviewed-by: dholmes, ihse ! make/common/shared/Defs.gmk Changeset: 34997920efe9 Author: erikj Date: 2013-09-23 17:38 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/34997920efe9 8025170: jdk7u51 7u-1-prebuild is failing since 9/19 Reviewed-by: tbell, ihse ! make/common/shared/Defs.gmk Changeset: 59a78e4ca635 Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/59a78e4ca635 Added tag jdk7u45-b13 for changeset 34997920efe9 ! .hgtags Changeset: ae181f7b46ee Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ae181f7b46ee Added tag jdk7u45-b14 for changeset 59a78e4ca635 ! .hgtags Changeset: 6f6b6f2ee50e Author: alanb Date: 2013-09-18 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6f6b6f2ee50e 8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx) Reviewed-by: alanb, coffeys Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java Changeset: 96782fe0c38c Author: dxu Date: 2013-09-27 00:01 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/96782fe0c38c 8025128: File.createTempFile fails if prefix is absolute path Reviewed-by: alanb, darcy ! src/share/classes/java/io/File.java ! test/java/io/File/createTempFile/SpecialTempFile.java Changeset: 3c9a6d9eafd3 Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3c9a6d9eafd3 Added tag jdk7u45-b15 for changeset 96782fe0c38c ! .hgtags Changeset: 7a0817613afa Author: asaha Date: 2013-10-01 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7a0817613afa Merge ! .hgtags - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/share/classes/java/util/TimeZone.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/sun/swing/SwingUtilities2.java ! test/java/io/IOException/LastErrorString.java Changeset: 26cc60a250a0 Author: katleman Date: 2013-09-11 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/26cc60a250a0 Added tag jdk7u40-b61 for changeset e045f6a3ad1d ! .hgtags Changeset: 5ef3a5490dc7 Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5ef3a5490dc7 Added tag jdk7u40-b62 for changeset 26cc60a250a0 ! .hgtags Changeset: ae5a0572178d Author: asaha Date: 2013-09-19 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ae5a0572178d Merge ! .hgtags Changeset: d1eb22609ec2 Author: asaha Date: 2013-09-27 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d1eb22609ec2 Merge ! .hgtags Changeset: 3a65c1b0c6d1 Author: cl Date: 2013-10-03 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3a65c1b0c6d1 Added tag jdk7u45-b16 for changeset 3c9a6d9eafd3 ! .hgtags Changeset: c5ca4daec23b Author: cl Date: 2013-10-07 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c5ca4daec23b Added tag jdk7u45-b17 for changeset 3a65c1b0c6d1 ! .hgtags Changeset: 4797f984f6c9 Author: cl Date: 2013-10-08 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4797f984f6c9 Added tag jdk7u45-b18 for changeset c5ca4daec23b ! .hgtags Changeset: 0d50077be529 Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0d50077be529 Added tag jdk7u45-b30 for changeset 4797f984f6c9 ! .hgtags Changeset: 8c343a783777 Author: asaha Date: 2013-10-08 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8c343a783777 Merge ! .hgtags Changeset: 1bb6eaa200ca Author: asaha Date: 2013-10-08 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1bb6eaa200ca Merge ! .hgtags Changeset: 95d67f7d8c95 Author: cl Date: 2013-10-09 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/95d67f7d8c95 Added tag jdk7u45-b31 for changeset 8c343a783777 ! .hgtags Changeset: ad7fa9ee6e7f Author: asaha Date: 2013-10-09 15:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ad7fa9ee6e7f Merge ! .hgtags Changeset: b5326675e374 Author: asaha Date: 2013-10-14 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b5326675e374 Merge ! .hgtags ! make/sun/awt/Makefile ! src/share/classes/java/lang/reflect/Proxy.java ! src/solaris/native/java/net/net_util_md.c From alejandro.murillo at oracle.com Wed Oct 23 16:23:13 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 23 Oct 2013 23:23:13 +0000 Subject: hg: hsx/jdk7u/langtools: 55 new changesets Message-ID: <20131023232555.C46AC626B9@hg.openjdk.java.net> Changeset: b2e29b79e54e Author: katleman Date: 2013-09-03 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b2e29b79e54e Added tag jdk7u40-b60 for changeset a67dbf96bf86 ! .hgtags Changeset: ec1e462694a9 Author: coffeys Date: 2013-09-23 12:09 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/ec1e462694a9 Merge Changeset: 4494e6cadb8c Author: lana Date: 2013-10-09 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/4494e6cadb8c Merge ! .hgtags Changeset: c7024dda4ff3 Author: asaha Date: 2013-06-20 21:27 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/c7024dda4ff3 Merge ! .hgtags Changeset: ca9a1ac71131 Author: asaha Date: 2013-06-21 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/ca9a1ac71131 Merge ! .hgtags Changeset: 9bbfba4981e1 Author: asaha Date: 2013-06-28 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/9bbfba4981e1 Merge ! .hgtags Changeset: b8ef7bb9c7b2 Author: katleman Date: 2013-07-02 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b8ef7bb9c7b2 Added tag jdk7u45-b01 for changeset 9bbfba4981e1 ! .hgtags Changeset: d27b39c92849 Author: asaha Date: 2013-07-03 17:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/d27b39c92849 Merge ! .hgtags Changeset: 61d5b73ae0ac Author: robm Date: 2013-07-09 03:31 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/61d5b73ae0ac 8016653: javadoc should ignore ignoreable characters in names Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/Scanner.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java Changeset: b9f4c87abb35 Author: katleman Date: 2013-07-09 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b9f4c87abb35 Added tag jdk7u45-b02 for changeset 61d5b73ae0ac ! .hgtags Changeset: 2fe27ae865e7 Author: asaha Date: 2013-07-10 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/2fe27ae865e7 Merge ! .hgtags Changeset: 57105bd6b5ce Author: cl Date: 2013-07-16 05:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/57105bd6b5ce Added tag jdk7u45-b03 for changeset 2fe27ae865e7 ! .hgtags Changeset: de93f4bc2c76 Author: bpatel Date: 2013-07-19 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/de93f4bc2c76 8016675: Make Javadoc pages more robust Reviewed-by: jlaskey, ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + test/com/sun/javadoc/testWindowTitle/TestWindowTitle.java + test/com/sun/javadoc/testWindowTitle/p1/C1.java + test/com/sun/javadoc/testWindowTitle/p2/C2.java Changeset: 416fe90ccdf5 Author: asaha Date: 2013-07-17 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/416fe90ccdf5 Merge ! .hgtags Changeset: bede296dc848 Author: asaha Date: 2013-07-22 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/bede296dc848 Merge Changeset: 4484d9bef277 Author: cl Date: 2013-07-23 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/4484d9bef277 Added tag jdk7u45-b04 for changeset bede296dc848 ! .hgtags Changeset: 6eb9444e0f46 Author: asaha Date: 2013-07-25 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/6eb9444e0f46 Merge ! .hgtags Changeset: dd914d8a6085 Author: asaha Date: 2013-07-29 12:01 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/dd914d8a6085 Merge Changeset: e989f2f2b5cb Author: asaha Date: 2013-07-31 23:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/e989f2f2b5cb Merge ! .hgtags Changeset: f7a971506d01 Author: asaha Date: 2013-08-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/f7a971506d01 Added tag jdk7u45-b05 for changeset e989f2f2b5cb ! .hgtags Changeset: 993a01f0ab41 Author: asaha Date: 2013-08-02 22:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/993a01f0ab41 Merge ! .hgtags Changeset: 63f7bbf8a72e Author: cl Date: 2013-08-02 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/63f7bbf8a72e Added tag jdk7u45-b05 for changeset 6eb9444e0f46 ! .hgtags Changeset: a6be1495ff24 Author: asaha Date: 2013-08-05 11:54 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/a6be1495ff24 8022254: Remove incorrect jdk7u45-b05 tag from jdk7u-cpu forest Reviewed-by: cl ! .hgtags Changeset: c8f4a544ada6 Author: asaha Date: 2013-08-05 13:50 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/c8f4a544ada6 Merge ! .hgtags Changeset: 6f492dc935ad Author: asaha Date: 2013-08-07 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/6f492dc935ad Merge ! .hgtags Changeset: 56f937be36eb Author: cl Date: 2013-08-08 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/56f937be36eb Added tag jdk7u45-b06 for changeset 6f492dc935ad ! .hgtags Changeset: 4c51f98e1eb5 Author: asaha Date: 2013-08-12 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/4c51f98e1eb5 Merge ! .hgtags Changeset: 240a9b79f6f7 Author: cl Date: 2013-08-15 22:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/240a9b79f6f7 Added tag jdk7u45-b07 for changeset 4c51f98e1eb5 ! .hgtags Changeset: 6cf97c9859e7 Author: asaha Date: 2013-08-19 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/6cf97c9859e7 Merge ! .hgtags Changeset: e6be5016d661 Author: cl Date: 2013-08-20 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/e6be5016d661 Added tag jdk7u45-b08 for changeset 6cf97c9859e7 ! .hgtags Changeset: 14277771a1b2 Author: asaha Date: 2013-08-22 08:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/14277771a1b2 Merge ! .hgtags Changeset: a9c31d3f8188 Author: asaha Date: 2013-08-26 08:48 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/a9c31d3f8188 Merge ! .hgtags Changeset: 1f1c0d891144 Author: cl Date: 2013-08-27 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/1f1c0d891144 Added tag jdk7u45-b09 for changeset a9c31d3f8188 ! .hgtags Changeset: 2c09352066ec Author: asaha Date: 2013-08-27 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/2c09352066ec Merge ! .hgtags Changeset: da8110204565 Author: cl Date: 2013-09-04 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/da8110204565 Added tag jdk7u45-b10 for changeset 2c09352066ec ! .hgtags Changeset: 53d5c06766b0 Author: asaha Date: 2013-09-04 12:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/53d5c06766b0 Merge ! .hgtags Changeset: 0b6aa6e95eb9 Author: cl Date: 2013-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/0b6aa6e95eb9 Added tag jdk7u45-b11 for changeset 53d5c06766b0 ! .hgtags Changeset: 68862f365075 Author: cl Date: 2013-09-18 02:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/68862f365075 Added tag jdk7u45-b12 for changeset 0b6aa6e95eb9 ! .hgtags Changeset: 8c799b9f0cd8 Author: cl Date: 2013-09-23 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/8c799b9f0cd8 Added tag jdk7u45-b13 for changeset 68862f365075 ! .hgtags Changeset: 36ae3f206b53 Author: cl Date: 2013-09-26 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/36ae3f206b53 Added tag jdk7u45-b14 for changeset 8c799b9f0cd8 ! .hgtags Changeset: 18d1864abca9 Author: cl Date: 2013-09-27 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/18d1864abca9 Added tag jdk7u45-b15 for changeset 36ae3f206b53 ! .hgtags Changeset: 5ac83d3faf41 Author: asaha Date: 2013-10-01 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/5ac83d3faf41 Merge ! .hgtags Changeset: 94ea3d062a3c Author: katleman Date: 2013-09-11 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/94ea3d062a3c Added tag jdk7u40-b61 for changeset b2e29b79e54e ! .hgtags Changeset: 89e8f0dd7d92 Author: katleman Date: 2013-09-17 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/89e8f0dd7d92 Added tag jdk7u40-b62 for changeset 94ea3d062a3c ! .hgtags Changeset: da3d82321828 Author: asaha Date: 2013-09-19 15:05 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/da3d82321828 Merge ! .hgtags Changeset: 5b0c0a847e13 Author: asaha Date: 2013-09-27 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/5b0c0a847e13 Merge ! .hgtags Changeset: b9aeec6b9d5a Author: cl Date: 2013-10-03 11:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b9aeec6b9d5a Added tag jdk7u45-b16 for changeset 18d1864abca9 ! .hgtags Changeset: ba3ff27d4082 Author: cl Date: 2013-10-07 21:53 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/ba3ff27d4082 Added tag jdk7u45-b17 for changeset b9aeec6b9d5a ! .hgtags Changeset: 164cf7491ba2 Author: cl Date: 2013-10-08 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/164cf7491ba2 Added tag jdk7u45-b18 for changeset ba3ff27d4082 ! .hgtags Changeset: 6daac5a4016a Author: cl Date: 2013-10-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/6daac5a4016a Added tag jdk7u45-b30 for changeset 164cf7491ba2 ! .hgtags Changeset: 7f5cfaedb25c Author: asaha Date: 2013-10-08 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/7f5cfaedb25c Merge ! .hgtags Changeset: 9580b3fb09fe Author: asaha Date: 2013-10-08 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/9580b3fb09fe Merge ! .hgtags Changeset: ef7bdbe7f1fa Author: cl Date: 2013-10-09 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/ef7bdbe7f1fa Added tag jdk7u45-b31 for changeset 7f5cfaedb25c ! .hgtags Changeset: b417c6d70bbd Author: asaha Date: 2013-10-09 15:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b417c6d70bbd Merge ! .hgtags Changeset: b19e375d9829 Author: asaha Date: 2013-10-14 23:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b19e375d9829 Merge ! .hgtags From alejandro.murillo at oracle.com Wed Oct 23 17:40:29 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 24 Oct 2013 00:40:29 +0000 Subject: hg: hsx/jdk7u/hotspot: 8027172: new hotspot build - hs24.60-b03 Message-ID: <20131024004040.41975626BB@hg.openjdk.java.net> Changeset: d240cdd354e3 Author: amurillo Date: 2013-10-23 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d240cdd354e3 8027172: new hotspot build - hs24.60-b03 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Wed Oct 23 18:05:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Oct 2013 11:05:49 +1000 Subject: RFR: 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build Message-ID: <5268726D.20009@oracle.com> This is a simple change with a complex background, so please bear with me. :) Here's the background. There is a class sun.misc.PostVMInitHook that only exists in the Oracle JDK (closed sources). There is a fragment of code in create_vm that runs this hook, if present, as part of the VM initialization sequence. This class is also on the list of well known classes to preload during early VM initialization (Universe::Genesis()->SystemDictionary::initialize()). The problem arises when an invalid jar file, eg a zero-length dummy.jar, is specified on -Xbootclasspath. In the Oracle JDK you will likely never discover that the invalid jar is present. During VM initialization all classes are in the meta-index that point to rt.jar and the "lazy loading" approach doesn't examine other entities on the bootclasspath unless necessary. So dummy.jar is completely ignored until the system classloader starts to load classes - at which point the bootloader upon not finding the class in the meta-index searches the bootclasspath, finds the invalid jar file and throws a ClassNotFoundException with a message about an invalid jar file. However the system (or extensions) loader expects the bootloader to throw such an exception if the required class can not be found on the bootclasspath (which it can't) and so continues to load it from the classpath and the application continues oblivious to the invalid jar. This is arguably not a good thing but not the subject of this particular change. ;-) In the OpenJDK the PostVMInitHook class does not exist so when preloading fails to find it in rt.jar as expected, the bootloader starts searching for it and encounters the invalid dummy.jar. So as previously described it triggers ClassNotFoundException to be thrown. However, the exception throwing logic in the VM has to watch for trying to throw exceptions during early VM initialization when the VM is not really ready to throw the exception. It sees VM initialization is still in progress so it instead calls vm_exit_during_initialization and the user sees: Error occurred during initialization of VM java/lang/ClassNotFoundException: error in opening JAR file dummy.jar So the Oracle JDK effectively ignored the invalid jar file while the OpenJDK aborts during VM initialization. There is a simple "fix" that allows the OpenJDK to behave the same as the Oracle JDK - we remove the PostVMInitHook class from the list of classes to preload. There's really no need for it to be preloaded and create_vm loads numerous classes that are not preloaded, so we simply handle this the same way. Now not finding the class during VM initialization doesn't trigger an exception (and if it did the logic would ignore it anyway). http://cr.openjdk.java.net/~dholmes/8026877/webrev/ Thanks for reading this far :) David From david.holmes at oracle.com Wed Oct 23 19:01:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Oct 2013 12:01:56 +1000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267E733.8010905@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> Message-ID: <52687F94.2010307@oracle.com> On 24/10/2013 1:11 AM, Artem Ananiev wrote: > > On 10/23/2013 4:34 PM, Anthony Petrov wrote: >> On 10/23/2013 08:52 AM, David Holmes wrote: >>> On 23/10/2013 2:10 PM, David DeHaven wrote: >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>>> >>>> Summary of changes since last: >>>> - Added awt_headless to java_props_t (set to NULL by default which >>>> does not set the property) >>> >>> Not sure about this part. We already force this property to be set in >>> Embedded without needing any changes in the code you have modified and >>> I'm not sure if your changes will break what we already do. Why do you >>> need to do it? >>> >>> I'm getting concerned about this change touching stuff outside of OSX. >> >> I think I agree with David. E.g. I'm not sure I like changing >> j/l/System.c for this fix. >> >> Given the time constraints, perhaps going with HToolkit would be a good >> enough solution for now? >> >> Artem, what's your opinion? > > I'm personally fine with the current version. The fix is now Mac OS X > specific, as sprops.awt_headless is only set within #ifdef MACOSX, Are we looking at the same code? This change in System.c: 209 if (sprops->awt_headless) { 210 PUTPROP(props, "java.awt.headless", sprops->awt_headless); 211 } is not in any ifdef. http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/src/share/native/java/lang/System.c.frames.html David H. -------- it > won't have any impact on other platforms. At the same time it enables > headless functionality on Mac OS X, while HToolkit doesn't. > > Note that it can be improved further. As it stands now, the only purpose > of getPreferredToolkit() is to check if Aqua session is active. The > toolkit we use is always CToolkit, regardless of what this method > returns, so the method can be removed, and isInAquaSession() can be > called instead. Leaving this further cleanup up to David D., though. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >>> >>> David >>> >>>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>>> could have just exposed isAquaSession but I wanted to preserve the >>>> AWT_TOOLKIT environment variable support (no idea if it's actually >>>> used or not...). >>>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>>> jtreg tests pass. >>>> >>>> No build system or hotspot changes since the last patch. >>>> >>>> -DrD- >>>> From david.holmes at oracle.com Wed Oct 23 19:25:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Oct 2013 12:25:52 +1000 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 In-Reply-To: <52682BE8.8090604@oracle.com> References: <5267DB44.5090108@oracle.com> <2E94A7FB-8F0C-4996-8EF0-8DA5E1040B4E@oracle.com> <52682BE8.8090604@oracle.com> Message-ID: <52688530.2040102@oracle.com> On 24/10/2013 6:04 AM, Gerard Ziemski wrote: > I like that check - the issue lies inside the kernel most likely, so any > fix would end up reving up the kernel version. Thank you. I'd certainly like to see the "fix" constrained to Mavericks. It seems strange to ask for the stacksize but then assume it is 2048 pages anyway. I assume OSX has some means of controlling the default initial stacksize? In which case this change will break things if a size smaller than 2048 is actually used. I'm concerned by this line in the table in the bug report, but don't understand what the "start JAVAVM" tag means: OS: USE_MAIN_THREAD: START_JAVAVM: CLAIMED PAGES: USABLE PAGES: 10.9 YES YES 128 124 won't your change break this case? Would checking only for the 128 value be more, or less, robust? Thanks, David > > On 10/23/2013 1:41 PM, Igor Veresov wrote: >> I guess it's reasonable. >> >> As for option (2) you can probably trigger the fix based on the kernel >> version, that is rather easy to get: >> >> #include >> #include >> char str[256]; >> size_t size = sizeof(str); >> int ret = sysctlbyname("kern.osrelease", str, &size, NULL, 0); >> >> Versions 13.x.x would be Mavericks. You can use it to put an >> additional assert. >> >> igor >> >> >> >> >> On Oct 23, 2013, at 7:20 AM, Gerard Ziemski > > wrote: >> >>> Please review this proposed workaround for OS X 10.9 (Mavericks) >>> >>> Description: >>> >>> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API >>> returns 128 pages for both main (primodial, primary) and secondary >>> threads, when in fact 2048 pages are available for the main thread. >>> pthread_get_stacksize_np() correctly returns 2048 pages for main >>> thread on 10.6, 10.7 and 10.8 and probably all previous OS X versions. >>> >>> An issue has been filed with Apple, but in the meantime we need to >>> substitute 2048 pages whenever pthread_get_stacksize_np() returns >>> anything else (ie. 128) on main thread. >>> >>> The workaround uses hardcoded value of 2048 pages for main thread, >>> because: >>> >>> 1. The correct value can in fact be found at runtime using signals >>> (please see my test case attached to the bug's JDK issue), however, >>> such code needs signal handlers and also takes about 3.5 ms, so it's >>> probably not a viable solution. >>> >>> 2. We could also look-up OS X version at runtime to only use the >>> workaround for 10.9, but that requires parsing an xml file, looking >>> for a value that is internationalized, so it's non trivial (though >>> might be doable assuming the time to execute is low enough) >>> >>> 3. All JDK8 supported OS X versions (ie. 10.7, 10.8) return 2048. >>> >>> In the future, this workaround might need to be revisited (ie. 2), >>> but I believe that it's reasonable for now, though I would love to >>> hear others opinions on this. >>> >>> >>> Testing: >>> >>> In progress... >>> >>> >>> References: >>> >>> http://cr.openjdk.java.net/~iklam/8020753/ziemski_rev1/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8020753 >>> >>> >>> cheers >>> >> > From christian.thalinger at oracle.com Wed Oct 23 20:16:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Oct 2013 20:16:51 -0700 Subject: RFR: 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build In-Reply-To: <5268726D.20009@oracle.com> References: <5268726D.20009@oracle.com> Message-ID: <47EC04A4-4D0D-4DE7-8966-4526056FB863@oracle.com> Wow. The change looks good. On Oct 23, 2013, at 6:05 PM, David Holmes wrote: > This is a simple change with a complex background, so please bear with me. :) > > Here's the background. There is a class sun.misc.PostVMInitHook that only exists in the Oracle JDK (closed sources). There is a fragment of code in create_vm that runs this hook, if present, as part of the VM initialization sequence. This class is also on the list of well known classes to preload during early VM initialization (Universe::Genesis()->SystemDictionary::initialize()). > > The problem arises when an invalid jar file, eg a zero-length dummy.jar, is specified on -Xbootclasspath. > > In the Oracle JDK you will likely never discover that the invalid jar is present. During VM initialization all classes are in the meta-index that point to rt.jar and the "lazy loading" approach doesn't examine other entities on the bootclasspath unless necessary. So dummy.jar is completely ignored until the system classloader starts to load classes - at which point the bootloader upon not finding the class in the meta-index searches the bootclasspath, finds the invalid jar file and throws a ClassNotFoundException with a message about an invalid jar file. However the system (or extensions) loader expects the bootloader to throw such an exception if the required class can not be found on the bootclasspath (which it can't) and so continues to load it from the classpath and the application continues oblivious to the invalid jar. This is arguably not a good thing but not the subject of this particular change. ;-) > > In the OpenJDK the PostVMInitHook class does not exist so when preloading fails to find it in rt.jar as expected, the bootloader starts searching for it and encounters the invalid dummy.jar. So as previously described it triggers ClassNotFoundException to be thrown. However, the exception throwing logic in the VM has to watch for trying to throw exceptions during early VM initialization when the VM is not really ready to throw the exception. It sees VM initialization is still in progress so it instead calls vm_exit_during_initialization and the user sees: > > Error occurred during initialization of VM > java/lang/ClassNotFoundException: error in opening JAR file dummy.jar > > So the Oracle JDK effectively ignored the invalid jar file while the OpenJDK aborts during VM initialization. > > There is a simple "fix" that allows the OpenJDK to behave the same as the Oracle JDK - we remove the PostVMInitHook class from the list of classes to preload. There's really no need for it to be preloaded and create_vm loads numerous classes that are not preloaded, so we simply handle this the same way. Now not finding the class during VM initialization doesn't trigger an exception (and if it did the logic would ignore it anyway). > > http://cr.openjdk.java.net/~dholmes/8026877/webrev/ > > Thanks for reading this far :) > > David From david.dehaven at oracle.com Wed Oct 23 20:52:09 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 23 Oct 2013 20:52:09 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> Message-ID: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> >>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >> >> I like this idea. But it needs testing. > > Cool, I'll poke at it when I get a chance. Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... Updated (hopefully final...) webrev: http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ Changes from last version: http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). -DrD- From coleen.phillimore at oracle.com Wed Oct 23 20:54:28 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Oct 2013 23:54:28 -0400 Subject: RFR: 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build In-Reply-To: <5268726D.20009@oracle.com> References: <5268726D.20009@oracle.com> Message-ID: <526899F4.7030709@oracle.com> This looks good. Do we use sun.misc.PostVMHook for anything? Coleen On 10/23/2013 9:05 PM, David Holmes wrote: > This is a simple change with a complex background, so please bear with > me. :) > > Here's the background. There is a class sun.misc.PostVMInitHook that > only exists in the Oracle JDK (closed sources). There is a fragment of > code in create_vm that runs this hook, if present, as part of the VM > initialization sequence. This class is also on the list of well known > classes to preload during early VM initialization > (Universe::Genesis()->SystemDictionary::initialize()). > > The problem arises when an invalid jar file, eg a zero-length > dummy.jar, is specified on -Xbootclasspath. > > In the Oracle JDK you will likely never discover that the invalid jar > is present. During VM initialization all classes are in the meta-index > that point to rt.jar and the "lazy loading" approach doesn't examine > other entities on the bootclasspath unless necessary. So dummy.jar is > completely ignored until the system classloader starts to load classes > - at which point the bootloader upon not finding the class in the > meta-index searches the bootclasspath, finds the invalid jar file and > throws a ClassNotFoundException with a message about an invalid jar > file. However the system (or extensions) loader expects the bootloader > to throw such an exception if the required class can not be found on > the bootclasspath (which it can't) and so continues to load it from > the classpath and the application continues oblivious to the invalid > jar. This is arguably not a good thing but not the subject of this > particular change. ;-) > > In the OpenJDK the PostVMInitHook class does not exist so when > preloading fails to find it in rt.jar as expected, the bootloader > starts searching for it and encounters the invalid dummy.jar. So as > previously described it triggers ClassNotFoundException to be thrown. > However, the exception throwing logic in the VM has to watch for > trying to throw exceptions during early VM initialization when the VM > is not really ready to throw the exception. It sees VM initialization > is still in progress so it instead calls vm_exit_during_initialization > and the user sees: > > Error occurred during initialization of VM > java/lang/ClassNotFoundException: error in opening JAR file open error> dummy.jar > > So the Oracle JDK effectively ignored the invalid jar file while the > OpenJDK aborts during VM initialization. > > There is a simple "fix" that allows the OpenJDK to behave the same as > the Oracle JDK - we remove the PostVMInitHook class from the list of > classes to preload. There's really no need for it to be preloaded and > create_vm loads numerous classes that are not preloaded, so we simply > handle this the same way. Now not finding the class during VM > initialization doesn't trigger an exception (and if it did the logic > would ignore it anyway). > > http://cr.openjdk.java.net/~dholmes/8026877/webrev/ > > Thanks for reading this far :) > > David From coleen.phillimore at oracle.com Wed Oct 23 21:03:38 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Oct 2013 00:03:38 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops Message-ID: <52689C1A.8040305@oracle.com> Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, reserve some space under 32G so compressed classes can have the same (more favorable) compression algorithm as oops. This change may have to be reverted when we implement extending compressed class spaces in the future, but it gets back the performance of these nashorn benchmarks, and seems to make sense for small heaps. open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ bug link https://bugs.openjdk.java.net/browse/JDK-8024927 Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 solaris/x64 and windows/x64 (in progress). Also running refworkload. Thanks, Coleen From stefan.karlsson at oracle.com Thu Oct 24 01:45:58 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 24 Oct 2013 10:45:58 +0200 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52689C1A.8040305@oracle.com> References: <52689C1A.8040305@oracle.com> Message-ID: <5268DE46.7050109@oracle.com> On 10/24/13 6:03 AM, Coleen Phillimore wrote: > Summary: Allocate compressed class space at end of Java heap. For > small heap sizes, without CDS, reserve some space under 32G so > compressed classes can have the same (more favorable) compression > algorithm as oops. > > This change may have to be reverted when we implement extending > compressed class spaces in the future, but it gets back the > performance of these nashorn benchmarks, and seems to make sense for > small heaps. > > open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ > bug link https://bugs.openjdk.java.net/browse/JDK-8024927 Hi Coleen, If I you run with a small heap, say -Xmx128m, you get shifted compressed klass pointers. Is that intentional? $ java -Xmx128m -XX:+PrintCompressedOopsMode -version heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed Oops, 32-bits Oops Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 Compressed class space size: 1073741824 Address: 0x0000000100000000 Req Addr: 0x0000000100000000 Some comments: http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html + uint64_t klass_encoding_max = NarrowOopHeapMax << LogKlassAlignmentInBytes; Shouldn't you be using this constant: ? const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + 1) << LogKlassAlignmentInBytes; 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << LogKlassAlignmentInBytes; 2819 // If compressed class space fits in lower 32G, we don't need a base. 2820 if (higher_address <= (address)klass_encoding_max) { 2821 Universe::set_narrow_klass_base(0); 2822 lower_base = 0; // effectively lower base is zero. 2823 } else { 2824 Universe::set_narrow_klass_base(lower_base); 2825 } 2826 2827 if ((uint64_t)(higher_address - lower_base) < (uint64_t)max_juint) { 2828 Universe::set_narrow_klass_shift(0); 2829 } else { 2830 assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces"); 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); 2832 } If you execute line 2822, will you hit the assert at line 2830 if you run with CDS and set SharedBaseAddress. $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed Oops, 32-bits Oops Loading classes to share ... done. Rewriting and linking classes ... done. Number of classes 2359 Calculating fingerprints ... done. Removing unshareable information ... done. ro space: 6895936 [ 34.7% of total] out of 16777216 bytes [41.1% used] at 0x0000000200000000 rw space: 10849560 [ 54.5% of total] out of 16777216 bytes [64.7% used] at 0x0000000201000000 md space: 2120272 [ 10.7% of total] out of 4194304 bytes [50.6% used] at 0x0000000202000000 mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% used] at 0x0000000202400000 total : 19899821 [100.0% of total] out of 37871616 bytes [52.5% used] $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed Oops, 32-bits Oops # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/metaspace.cpp:2874 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/stefank/hg/hsx-gc/src/share/vm/memory/metaspace.cpp:2874), pid=32067, tid=140386534242048 # assert(!UseSharedSpaces) failed: Cannot shift with UseSharedSpaces # # JRE version: (8.0-b110) (build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b55-internal-debug mixed mode, sharing linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /localhome/tests/SPECjbb2005/hs_err_pid32067.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); 2854 assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); Could you keep the alignment, or remove it? - allocate_metaspace_compressed_klass_ptrs((char *)CompressedKlassPointersBase, 0); + char* base = (char*)Universe::heap()->reserved_region().end(); + allocate_metaspace_compressed_klass_ptrs(base, 0); You need to make sure that 'base' address is aligned against Metaspace::reserve_alignment(). http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html + if (UseCompressedClassPointers && + LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes) { + // For small heaps, save some space for compressed class pointer + // space with no base, only when ObjAlignmentInBytes is 64 bits. + uint64_t class_space = align_size_up(CompressedClassSpaceSize, alignment); + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, + alignment), "difference must be aligned too"); + uint64_t new_top = OopEncodingHeapMax-class_space; + + if (total_size <= new_top) { + base = (new_top - heap_size); + } else { + base = (OopEncodingHeapMax - heap_size); + } I don't understand why you have this restriction: LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes thanks, StefanK > > Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 > solaris/x64 and windows/x64 (in progress). Also running refworkload. > > Thanks, > Coleen From goetz.lindenmaier at sap.com Thu Oct 24 02:16:55 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Oct 2013 09:16:55 +0000 Subject: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52689C1A.8040305@oracle.com> References: <52689C1A.8040305@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D044EEE@DEWDFEMB12A.global.corp.sap> Hi Coleen, I appreciate this change a lot. As you touch this anyways, I would propose to rename NarrowOopHeapMax to UnscaledOopHeapMax. Narrow is also used in contexts where scaling is required, thus I find this is a misleading name for the 4G boundary. The following are my more general thoughts about this issue, not directly to be considered by this change: I think especially maintaining two different bases as in the current approach is expensive. Wouldn't it be feasible to use the same base for both spaces (oops and classes)? The class space could be placed below the base, so that decompression requires a subtraction. This would be a bit more expensive on platforms where shladd exists, but loading the two bases is much more expensive. Alternatively one could use negative compressed classes, loading them with sign extension. This would require that the sign bit is set, effectively limiting the compressed class space to halve of the heap. For big heaps one could even think of putting the class space into the lower regions so that no base is needed. One would end up with four configurations: Oop space class space Small: no base no base Medium: no base base Big: base no base XXXL: base base This should all be compatible with extending the compressed class space. There should be a natural upper bound to class space given the heap size, At least (2*class space) < heap should hold. 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: Donnerstag, 24. Oktober 2013 06:04 To: hotspot-dev Source Developers Subject: RFR: 8024927: Nashorn performance regression with CompressedOops Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, reserve some space under 32G so compressed classes can have the same (more favorable) compression algorithm as oops. This change may have to be reverted when we implement extending compressed class spaces in the future, but it gets back the performance of these nashorn benchmarks, and seems to make sense for small heaps. open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ bug link https://bugs.openjdk.java.net/browse/JDK-8024927 Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 solaris/x64 and windows/x64 (in progress). Also running refworkload. Thanks, Coleen From gerard.ziemski at oracle.com Thu Oct 24 04:49:52 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 24 Oct 2013 06:49:52 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 In-Reply-To: <52688530.2040102@oracle.com> References: <5267DB44.5090108@oracle.com> <2E94A7FB-8F0C-4996-8EF0-8DA5E1040B4E@oracle.com> <52682BE8.8090604@oracle.com> <52688530.2040102@oracle.com> Message-ID: <52690960.3060600@oracle.com> On 10/23/2013 9:25 PM, David Holmes wrote: > On 24/10/2013 6:04 AM, Gerard Ziemski wrote: >> I like that check - the issue lies inside the kernel most likely, so any >> fix would end up reving up the kernel version. Thank you. > > I'd certainly like to see the "fix" constrained to Mavericks. It seems > strange to ask for the stacksize but then assume it is 2048 pages > anyway. I assume OSX has some means of controlling the default initial > stacksize? In which case this change will break things if a size > smaller than 2048 is actually used. According to Apple's own doc on threads https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html the main thread is 8MB (2048 pages) and I don't see any way to change main thread's stack size. > I'm concerned by this line in the table in the bug report, but don't > understand what the "start JAVAVM" tag means: > > OS: USE_MAIN_THREAD: START_JAVAVM: CLAIMED PAGES: USABLE PAGES: > 10.9 YES YES 128 124 > > won't your change break this case? That line in fact shows that JavaVM currently breaks the main stack size for 3rd party code (it unnecessarily restricts the stack size to 128 even though 2048 pages are really available) and the presented workaround would in fact fox it. > > Would checking only for the 128 value be more, or less, robust? I considered checking for 128 pages as well, but according to the link I provided to Apple doc, the main thread on OS X is 2048 pages, so that's a good number to check. I believe restricting the workaround to Mavericks alleviates most concerns, but I agree that anything short of actually finding the stack size at runtime (which unfortunately is a no go here due to complexity and time cost) feels like well, a workaround. Thank you David for the insightful questions. From coleen.phillimore at oracle.com Thu Oct 24 06:01:49 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Oct 2013 09:01:49 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <5268DE46.7050109@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> Message-ID: <52691A3D.30409@oracle.com> Stefan, Thank you for the quick code review and testing. On 10/24/2013 4:45 AM, Stefan Karlsson wrote: > On 10/24/13 6:03 AM, Coleen Phillimore wrote: >> Summary: Allocate compressed class space at end of Java heap. For >> small heap sizes, without CDS, reserve some space under 32G so >> compressed classes can have the same (more favorable) compression >> algorithm as oops. >> >> This change may have to be reverted when we implement extending >> compressed class spaces in the future, but it gets back the >> performance of these nashorn benchmarks, and seems to make sense for >> small heaps. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 > > Hi Coleen, > > If I you run with a small heap, say -Xmx128m, you get shifted > compressed klass pointers. Is that intentional? > > $ java -Xmx128m -XX:+PrintCompressedOopsMode -version > > heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed > Oops, 32-bits Oops > > Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 > Compressed class space size: 1073741824 Address: 0x0000000100000000 > Req Addr: 0x0000000100000000 > The top address 0x0000000100000000 + size must require the shift, since the base is zero (ie, the code did this math). > > Some comments: > > http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html > > > + uint64_t klass_encoding_max = NarrowOopHeapMax << > LogKlassAlignmentInBytes; > > Shouldn't you be using this constant: ? > const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + 1) > << LogKlassAlignmentInBytes; > Yes, it's the same constant as NarrowOopHeapMax so I made it common. I guess the name is confusing so I reverted that bit of the change and have a copy of the constant in the code. > > 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << > LogKlassAlignmentInBytes; > 2819 // If compressed class space fits in lower 32G, we don't need a > base. > 2820 if (higher_address <= (address)klass_encoding_max) { > 2821 Universe::set_narrow_klass_base(0); > 2822 lower_base = 0; // effectively lower base is zero. > 2823 } else { > 2824 Universe::set_narrow_klass_base(lower_base); > 2825 } > 2826 > 2827 if ((uint64_t)(higher_address - lower_base) < > (uint64_t)max_juint) { > 2828 Universe::set_narrow_klass_shift(0); > 2829 } else { > 2830 assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces"); > 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); > 2832 } > > If you execute line 2822, will you hit the assert at line 2830 if you > run with CDS and set SharedBaseAddress. > > $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g > -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version > ... > $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g > -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version > ... I hadn't completely excluded UseSharedSpaces from this change, which I intended to do. I fixed this now. > > 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); > 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); > 2854 assert_is_size_aligned(compressed_class_space_size(), > _reserve_alignment); > > Could you keep the alignment, or remove it? What do you mean? > > > - allocate_metaspace_compressed_klass_ptrs((char > *)CompressedKlassPointersBase, 0); > + char* base = (char*)Universe::heap()->reserved_region().end(); > + allocate_metaspace_compressed_klass_ptrs(base, 0); > > You need to make sure that 'base' address is aligned against > Metaspace::reserve_alignment(). > Fixed. > > http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html > > > + if (UseCompressedClassPointers && > + LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes) { > + // For small heaps, save some space for compressed class > pointer > + // space with no base, only when ObjAlignmentInBytes is > 64 bits. > + uint64_t class_space = > align_size_up(CompressedClassSpaceSize, alignment); > + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, > + alignment), "difference must be aligned too"); > + uint64_t new_top = OopEncodingHeapMax-class_space; > + > + if (total_size <= new_top) { > + base = (new_top - heap_size); > + } else { > + base = (OopEncodingHeapMax - heap_size); > + } > > I don't understand why you have this restriction: > LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes > Because if you use a bigger ObjAlignmentInBytes, you probably have a bigger heap and this won't work anyway and I didn't want to support and test it. I am rerunning some tests on the fixes. I'll send out another webrev shortly. Thanks so much for breaking my code! Srsly. Coleen > thanks, > StefanK > >> >> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >> solaris/x64 and windows/x64 (in progress). Also running refworkload. >> >> Thanks, >> Coleen > From stefan.karlsson at oracle.com Thu Oct 24 06:20:59 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 24 Oct 2013 15:20:59 +0200 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52691A3D.30409@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> Message-ID: <52691EBB.50103@oracle.com> On 10/24/13 3:01 PM, Coleen Phillimore wrote: > > Stefan, > > Thank you for the quick code review and testing. > > On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>> Summary: Allocate compressed class space at end of Java heap. For >>> small heap sizes, without CDS, reserve some space under 32G so >>> compressed classes can have the same (more favorable) compression >>> algorithm as oops. >>> >>> This change may have to be reverted when we implement extending >>> compressed class spaces in the future, but it gets back the >>> performance of these nashorn benchmarks, and seems to make sense for >>> small heaps. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >> >> Hi Coleen, >> >> If I you run with a small heap, say -Xmx128m, you get shifted >> compressed klass pointers. Is that intentional? >> >> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >> >> heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed >> Oops, 32-bits Oops >> >> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >> Compressed class space size: 1073741824 Address: 0x0000000100000000 >> Req Addr: 0x0000000100000000 >> > > The top address 0x0000000100000000 + size must require the shift, > since the base is zero (ie, the code did this math). Sure. But do we want the top address to be 0x0000000100000000 when we probably could fit both heap and the compressed class space in the lower 4GB? But let's ignore that for this change. >> >> Some comments: >> >> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >> >> >> + uint64_t klass_encoding_max = NarrowOopHeapMax << >> LogKlassAlignmentInBytes; >> >> Shouldn't you be using this constant: ? >> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + 1) >> << LogKlassAlignmentInBytes; >> > > Yes, it's the same constant as NarrowOopHeapMax so I made it common. > I guess the name is confusing so I reverted that bit of the change and > have a copy of the constant in the code. OK. I'll check the new webrev. > >> >> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >> LogKlassAlignmentInBytes; >> 2819 // If compressed class space fits in lower 32G, we don't need >> a base. >> 2820 if (higher_address <= (address)klass_encoding_max) { >> 2821 Universe::set_narrow_klass_base(0); >> 2822 lower_base = 0; // effectively lower base is zero. >> 2823 } else { >> 2824 Universe::set_narrow_klass_base(lower_base); >> 2825 } >> 2826 >> 2827 if ((uint64_t)(higher_address - lower_base) < >> (uint64_t)max_juint) { >> 2828 Universe::set_narrow_klass_shift(0); >> 2829 } else { >> 2830 assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces"); >> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >> 2832 } >> >> If you execute line 2822, will you hit the assert at line 2830 if you >> run with CDS and set SharedBaseAddress. >> >> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >> ... >> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >> ... > > I hadn't completely excluded UseSharedSpaces from this change, which I > intended to do. I fixed this now. > >> >> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >> 2854 assert_is_size_aligned(compressed_class_space_size(), >> _reserve_alignment); >> >> Could you keep the alignment, or remove it? > > What do you mean? I mean that you messed up the indentation of _reserve_alignment. Maybe a copy and past from the patch will show this: assert_is_ptr_aligned(requested_addr, _reserve_alignment); assert_is_ptr_aligned(cds_base, _reserve_alignment); - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); >> >> >> - allocate_metaspace_compressed_klass_ptrs((char >> *)CompressedKlassPointersBase, 0); >> + char* base = (char*)Universe::heap()->reserved_region().end(); >> + allocate_metaspace_compressed_klass_ptrs(base, 0); >> >> You need to make sure that 'base' address is aligned against >> Metaspace::reserve_alignment(). >> > > Fixed. > >> >> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >> >> >> + if (UseCompressedClassPointers && >> + LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes) { >> + // For small heaps, save some space for compressed class >> pointer >> + // space with no base, only when ObjAlignmentInBytes is >> 64 bits. >> + uint64_t class_space = >> align_size_up(CompressedClassSpaceSize, alignment); >> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >> + alignment), "difference must be aligned too"); >> + uint64_t new_top = OopEncodingHeapMax-class_space; >> + >> + if (total_size <= new_top) { >> + base = (new_top - heap_size); >> + } else { >> + base = (OopEncodingHeapMax - heap_size); >> + } >> >> I don't understand why you have this restriction: >> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >> > > Because if you use a bigger ObjAlignmentInBytes, you probably have a > bigger heap and this won't work anyway and I didn't want to support > and test it. OK. Could you change the check to compare LogMinObjAlignmentInBytes to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? That would be much more clear too me. > I am rerunning some tests on the fixes. I'll send out another webrev > shortly. > > Thanks so much for breaking my code! Srsly. OK. I'll wait for the update. thanks, StefanK > > Coleen > >> thanks, >> StefanK >> >>> >>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Thu Oct 24 06:39:26 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Oct 2013 09:39:26 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52691EBB.50103@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> Message-ID: <5269230E.3070804@oracle.com> Stefan, see below. On 10/24/2013 9:20 AM, Stefan Karlsson wrote: > On 10/24/13 3:01 PM, Coleen Phillimore wrote: >> >> Stefan, >> >> Thank you for the quick code review and testing. >> >> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>> Summary: Allocate compressed class space at end of Java heap. For >>>> small heap sizes, without CDS, reserve some space under 32G so >>>> compressed classes can have the same (more favorable) compression >>>> algorithm as oops. >>>> >>>> This change may have to be reverted when we implement extending >>>> compressed class spaces in the future, but it gets back the >>>> performance of these nashorn benchmarks, and seems to make sense >>>> for small heaps. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>> >>> Hi Coleen, >>> >>> If I you run with a small heap, say -Xmx128m, you get shifted >>> compressed klass pointers. Is that intentional? >>> >>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>> >>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>> Compressed Oops, 32-bits Oops >>> >>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>> Compressed class space size: 1073741824 Address: 0x0000000100000000 >>> Req Addr: 0x0000000100000000 >>> >> >> The top address 0x0000000100000000 + size must require the shift, >> since the base is zero (ie, the code did this math). > > Sure. But do we want the top address to be 0x0000000100000000 when we > probably could fit both heap and the compressed class space in the > lower 4GB? But let's ignore that for this change. > >>> >>> Some comments: >>> >>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>> >>> >>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>> LogKlassAlignmentInBytes; >>> >>> Shouldn't you be using this constant: ? >>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + >>> 1) << LogKlassAlignmentInBytes; >>> >> >> Yes, it's the same constant as NarrowOopHeapMax so I made it common. >> I guess the name is confusing so I reverted that bit of the change >> and have a copy of the constant in the code. > > OK. I'll check the new webrev. > >> >>> >>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>> LogKlassAlignmentInBytes; >>> 2819 // If compressed class space fits in lower 32G, we don't need >>> a base. >>> 2820 if (higher_address <= (address)klass_encoding_max) { >>> 2821 Universe::set_narrow_klass_base(0); >>> 2822 lower_base = 0; // effectively lower base is zero. >>> 2823 } else { >>> 2824 Universe::set_narrow_klass_base(lower_base); >>> 2825 } >>> 2826 >>> 2827 if ((uint64_t)(higher_address - lower_base) < >>> (uint64_t)max_juint) { >>> 2828 Universe::set_narrow_klass_shift(0); >>> 2829 } else { >>> 2830 assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces"); >>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>> 2832 } >>> >>> If you execute line 2822, will you hit the assert at line 2830 if >>> you run with CDS and set SharedBaseAddress. >>> >>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>> ... >>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>> ... >> >> I hadn't completely excluded UseSharedSpaces from this change, which >> I intended to do. I fixed this now. >> >>> >>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>> _reserve_alignment); >>> >>> Could you keep the alignment, or remove it? >> >> What do you mean? > > I mean that you messed up the indentation of _reserve_alignment. Maybe > a copy and past from the patch will show this: > assert_is_ptr_aligned(requested_addr, _reserve_alignment); > assert_is_ptr_aligned(cds_base, _reserve_alignment); > - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); > + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); Oh THAT alignment. I removed it since it looked funny with so many spaces. > >>> >>> >>> - allocate_metaspace_compressed_klass_ptrs((char >>> *)CompressedKlassPointersBase, 0); >>> + char* base = (char*)Universe::heap()->reserved_region().end(); >>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>> >>> You need to make sure that 'base' address is aligned against >>> Metaspace::reserve_alignment(). >>> >> >> Fixed. >> >>> >>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>> >>> >>> + if (UseCompressedClassPointers && >>> + LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes) { >>> + // For small heaps, save some space for compressed >>> class pointer >>> + // space with no base, only when ObjAlignmentInBytes is >>> 64 bits. >>> + uint64_t class_space = >>> align_size_up(CompressedClassSpaceSize, alignment); >>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>> + alignment), "difference must be aligned too"); >>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>> + >>> + if (total_size <= new_top) { >>> + base = (new_top - heap_size); >>> + } else { >>> + base = (OopEncodingHeapMax - heap_size); >>> + } >>> >>> I don't understand why you have this restriction: >>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>> >> >> Because if you use a bigger ObjAlignmentInBytes, you probably have a >> bigger heap and this won't work anyway and I didn't want to support >> and test it. > > OK. Could you change the check to compare LogMinObjAlignmentInBytes to > 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? That > would be much more clear too me. I don't like constants in code, which is why I picked the symbolic class alignment name for "3". I'll add a comment. How about that? thanks, Coleen > >> I am rerunning some tests on the fixes. I'll send out another webrev >> shortly. >> >> Thanks so much for breaking my code! Srsly. > > OK. I'll wait for the update. > > thanks, > StefanK >> >> Coleen >> >>> thanks, >>> StefanK >>> >>>> >>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>>> >>>> Thanks, >>>> Coleen >>> >> > From stefan.karlsson at oracle.com Thu Oct 24 06:49:57 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 24 Oct 2013 15:49:57 +0200 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <5269230E.3070804@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269230E.3070804@oracle.com> Message-ID: <52692585.7040907@oracle.com> On 10/24/13 3:39 PM, Coleen Phillimore wrote: > > Stefan, see below. > > On 10/24/2013 9:20 AM, Stefan Karlsson wrote: >> On 10/24/13 3:01 PM, Coleen Phillimore wrote: >>> >>> Stefan, >>> >>> Thank you for the quick code review and testing. >>> >>> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>>> Summary: Allocate compressed class space at end of Java heap. For >>>>> small heap sizes, without CDS, reserve some space under 32G so >>>>> compressed classes can have the same (more favorable) compression >>>>> algorithm as oops. >>>>> >>>>> This change may have to be reverted when we implement extending >>>>> compressed class spaces in the future, but it gets back the >>>>> performance of these nashorn benchmarks, and seems to make sense >>>>> for small heaps. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>>> >>>> Hi Coleen, >>>> >>>> If I you run with a small heap, say -Xmx128m, you get shifted >>>> compressed klass pointers. Is that intentional? >>>> >>>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>>> >>>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>>> Compressed Oops, 32-bits Oops >>>> >>>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>>> Compressed class space size: 1073741824 Address: 0x0000000100000000 >>>> Req Addr: 0x0000000100000000 >>>> >>> >>> The top address 0x0000000100000000 + size must require the shift, >>> since the base is zero (ie, the code did this math). >> >> Sure. But do we want the top address to be 0x0000000100000000 when we >> probably could fit both heap and the compressed class space in the >> lower 4GB? But let's ignore that for this change. >> >>>> >>>> Some comments: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>>> >>>> >>>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>>> LogKlassAlignmentInBytes; >>>> >>>> Shouldn't you be using this constant: ? >>>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + >>>> 1) << LogKlassAlignmentInBytes; >>>> >>> >>> Yes, it's the same constant as NarrowOopHeapMax so I made it >>> common. I guess the name is confusing so I reverted that bit of the >>> change and have a copy of the constant in the code. >> >> OK. I'll check the new webrev. >> >>> >>>> >>>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>>> LogKlassAlignmentInBytes; >>>> 2819 // If compressed class space fits in lower 32G, we don't >>>> need a base. >>>> 2820 if (higher_address <= (address)klass_encoding_max) { >>>> 2821 Universe::set_narrow_klass_base(0); >>>> 2822 lower_base = 0; // effectively lower base is zero. >>>> 2823 } else { >>>> 2824 Universe::set_narrow_klass_base(lower_base); >>>> 2825 } >>>> 2826 >>>> 2827 if ((uint64_t)(higher_address - lower_base) < >>>> (uint64_t)max_juint) { >>>> 2828 Universe::set_narrow_klass_shift(0); >>>> 2829 } else { >>>> 2830 assert(!UseSharedSpaces, "Cannot shift with >>>> UseSharedSpaces"); >>>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>>> 2832 } >>>> >>>> If you execute line 2822, will you hit the assert at line 2830 if >>>> you run with CDS and set SharedBaseAddress. >>>> >>>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>> ... >>>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>> ... >>> >>> I hadn't completely excluded UseSharedSpaces from this change, which >>> I intended to do. I fixed this now. >>> >>>> >>>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>>> _reserve_alignment); >>>> >>>> Could you keep the alignment, or remove it? >>> >>> What do you mean? >> >> I mean that you messed up the indentation of _reserve_alignment. >> Maybe a copy and past from the patch will show this: >> assert_is_ptr_aligned(requested_addr, _reserve_alignment); >> assert_is_ptr_aligned(cds_base, _reserve_alignment); >> - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); >> + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); > > > Oh THAT alignment. I removed it since it looked funny with so many > spaces. > >>>> >>>> >>>> - allocate_metaspace_compressed_klass_ptrs((char >>>> *)CompressedKlassPointersBase, 0); >>>> + char* base = >>>> (char*)Universe::heap()->reserved_region().end(); >>>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>>> >>>> You need to make sure that 'base' address is aligned against >>>> Metaspace::reserve_alignment(). >>>> >>> >>> Fixed. >>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>>> >>>> >>>> + if (UseCompressedClassPointers && >>>> + LogMinObjAlignmentInBytes == >>>> LogKlassAlignmentInBytes) { >>>> + // For small heaps, save some space for compressed >>>> class pointer >>>> + // space with no base, only when ObjAlignmentInBytes >>>> is 64 bits. >>>> + uint64_t class_space = >>>> align_size_up(CompressedClassSpaceSize, alignment); >>>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>> + alignment), "difference must be aligned too"); >>>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>>> + >>>> + if (total_size <= new_top) { >>>> + base = (new_top - heap_size); >>>> + } else { >>>> + base = (OopEncodingHeapMax - heap_size); >>>> + } >>>> >>>> I don't understand why you have this restriction: >>>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>>> >>> >>> Because if you use a bigger ObjAlignmentInBytes, you probably have a >>> bigger heap and this won't work anyway and I didn't want to support >>> and test it. >> >> OK. Could you change the check to compare LogMinObjAlignmentInBytes >> to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? >> That would be much more clear too me. > > I don't like constants in code, which is why I picked the symbolic > class alignment name for "3". I'll add a comment. How about that? But it's just wrong to use the symbolic class alignment (LogKlassAlignmentInBytes) here. What you need to check for is the heap size and not the klass alignments. Using LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes makes the code hard for me (and probably others) to understand. It might even introduce bugs if someone changes LogKlassAlignmentInBytes to 4 and and uses 16 byte object aligment (yes, I know other places will break too). thanks, StefanK > thanks, > Coleen > >> >>> I am rerunning some tests on the fixes. I'll send out another >>> webrev shortly. >>> >>> Thanks so much for breaking my code! Srsly. >> >> OK. I'll wait for the update. >> >> thanks, >> StefanK >>> >>> Coleen >>> >>>> thanks, >>>> StefanK >>>> >>>>> >>>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From yekaterina.kantserova at oracle.com Thu Oct 24 06:57:03 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 24 Oct 2013 15:57:03 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> <52663633.2080206@oracle.com> <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> Message-ID: <5269272F.6090907@oracle.com> Hi, I've done following big changes after the Staffan's review: - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM - tools will be launched without -vmoptions plusmade fixes for all minor comments. If it's a good idea to push testlibrary changes separately I can make a separate patch for them. Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 Thanks, Katja On 10/23/2013 12:55 PM, Staffan Larsen wrote: > test/lib/testlibrary/jdk/testlibrary/Asserts.java > Same code as already exists in the hotspot testlibrary. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/ProcessThread.java > L33: stating -> starting > L66: staring -> starting > > > test/lib/testlibrary/jdk/testlibrary/TestThread.java > This code comes from an internal test library. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/Utils.java > No comments. > > > test/lib/testlibrary/jdk/testlibrary/XRun.java > This code comes from an internal test library. > No further comments. > > > test/sun/tools/jstatd/JstatGcutilParser.java > The parse() method could be made more robust by discarding any lines > that come before the header lines. This can happen if the JVM outputs > a warning message for some reason before running jstat. > I don't like the special-case for the CCS column in verify() - took > me a while to find it. Should we add a new enum called > PERCENTAGE_OR_DASH to handle that instead? > > L67: getType() should be private. > > > test/sun/tools/jstatd/JstatdHelper.java: > L54: Does verifyJpsOutput() work correctly with output of the form: > > 1234 -- main class information unavailable > 1235 -- process information unavailable > > Also: same comment here as for JstatGcutilParser.java: sometimes the > JVM outputs warning messages before the output from the tool. > > L46: "attach" is probably not the best way to describe the operation > of jps. It does not attach to the process, it merely lists the running > processes. Perhaps runJps() is a better name? > > > test/sun/tools/jstatd/TestJstatdDefaults.java > test/sun/tools/jstatd/TestJstatdExternalRegistry.java > test/sun/tools/jstatd/TestJstatdPort.java > test/sun/tools/jstatd/TestJstatdPortAndServer.java > test/sun/tools/jstatd/TestJstatdServer.java > No comments. > > > test/sun/tools/jstatd/TestJstatdUsage.java > Same comment here as for JstatGcutilParser.java: sometimes the JVM > outputs warning messages before the output from the tool. > > > test/sun/tools/jstatd/ToolConfig.java > ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar > things to JDKToolLauncher in the hotspot testlibrary. It is > unfortunate if we have two ways to do similar things in the two > different testlibraries. Would it be possible to reuse the hotspot > code here instead? > > You have also changed the test. Previously the tools were not > launched with the jtreg -vmoptions (test.vm.opts), whereas now they > will be. Is this intentional? > > > General comments: > > Can't we do: > * @library /lib/testlibrary > instead of > * @library ../../../lib/testlibrary > ? > > It seems that at least some of the functionality should be reused for > re-writing the jstat and jps tests as well. I guess we can look at > that at a later time, though. > > While I applaud the move from shell scripts to Java code, I can't > shake the feeling that the shell scripts were easier to read and > follow. The Java code is much more verbose and spread out over > multiple helpers and libraries, making it harder to grasp. That may be > the price we have to pay, though. > > > Thanks, > /Staffan From coleen.phillimore at oracle.com Thu Oct 24 07:03:35 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Oct 2013 10:03:35 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52692585.7040907@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269230E.3070804@oracle.com> <52692585.7040907@oracle.com> Message-ID: <526928B7.70208@oracle.com> On 10/24/2013 9:49 AM, Stefan Karlsson wrote: >>> OK. Could you change the check to compare LogMinObjAlignmentInBytes >>> to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? >>> That would be much more clear too me. >> >> I don't like constants in code, which is why I picked the symbolic >> class alignment name for "3". I'll add a comment. How about that? > > But it's just wrong to use the symbolic class alignment > (LogKlassAlignmentInBytes) here. What you need to check for is the > heap size and not the klass alignments. Using > LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes makes the code > hard for me (and probably others) to understand. It might even > introduce bugs if someone changes LogKlassAlignmentInBytes to 4 and > and uses 16 byte object aligment (yes, I know other places will break > too). You're right I want OopEncodingHeapMax to be 32*G which it might be bigger with ObjectAlignmentInBytes. I'll just put 32*G since I can't find a symbolic constant for it. Coleen From artem.ananiev at oracle.com Thu Oct 24 07:03:36 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 18:03:36 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52687F94.2010307@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <52687F94.2010307@oracle.com> Message-ID: <526928B8.9010106@oracle.com> On 10/24/2013 6:01 AM, David Holmes wrote: > On 24/10/2013 1:11 AM, Artem Ananiev wrote: >> >> On 10/23/2013 4:34 PM, Anthony Petrov wrote: >>> On 10/23/2013 08:52 AM, David Holmes wrote: >>>> On 23/10/2013 2:10 PM, David DeHaven wrote: >>>>> >>>>> Updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>>>> >>>>> Summary of changes since last: >>>>> - Added awt_headless to java_props_t (set to NULL by default which >>>>> does not set the property) >>>> >>>> Not sure about this part. We already force this property to be set in >>>> Embedded without needing any changes in the code you have modified and >>>> I'm not sure if your changes will break what we already do. Why do you >>>> need to do it? >>>> >>>> I'm getting concerned about this change touching stuff outside of OSX. >>> >>> I think I agree with David. E.g. I'm not sure I like changing >>> j/l/System.c for this fix. >>> >>> Given the time constraints, perhaps going with HToolkit would be a good >>> enough solution for now? >>> >>> Artem, what's your opinion? >> >> I'm personally fine with the current version. The fix is now Mac OS X >> specific, as sprops.awt_headless is only set within #ifdef MACOSX, > > Are we looking at the same code? This change in System.c: I was looking at java_props_md.c. Anyway, in version .03 of the fix this block in System.c is put to #ifdef MACOSX as well. Thanks, Artem > 209 if (sprops->awt_headless) { > 210 PUTPROP(props, "java.awt.headless", sprops->awt_headless); > 211 } > > is not in any ifdef. > > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/src/share/native/java/lang/System.c.frames.html > > > David H. > -------- > > it >> won't have any impact on other platforms. At the same time it enables >> headless functionality on Mac OS X, while HToolkit doesn't. >> >> Note that it can be improved further. As it stands now, the only purpose >> of getPreferredToolkit() is to check if Aqua session is active. The >> toolkit we use is always CToolkit, regardless of what this method >> returns, so the method can be removed, and isInAquaSession() can be >> called instead. Leaving this further cleanup up to David D., though. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> David >>>> >>>>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>>>> could have just exposed isAquaSession but I wanted to preserve the >>>>> AWT_TOOLKIT environment variable support (no idea if it's actually >>>>> used or not...). >>>>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>>>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>>>> jtreg tests pass. >>>>> >>>>> No build system or hotspot changes since the last patch. >>>>> >>>>> -DrD- >>>>> From artem.ananiev at oracle.com Thu Oct 24 07:05:36 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 18:05:36 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> Message-ID: <52692930.7050307@oracle.com> Hi, David, .03 looks fine. Thanks for investigation, addressing all our comments, and this cleanup in general. Artem On 10/24/2013 7:52 AM, David DeHaven wrote: > >>>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >>> >>> I like this idea. But it needs testing. >> >> Cool, I'll poke at it when I get a chance. > > Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. > > It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. > > I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... > > > Updated (hopefully final...) webrev: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ > > Changes from last version: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html > > (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) > > > As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). > > -DrD- > From coleen.phillimore at oracle.com Thu Oct 24 07:31:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Oct 2013 10:31:13 -0400 Subject: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D044EEE@DEWDFEMB12A.global.corp.sap> References: <52689C1A.8040305@oracle.com> <4295855A5C1DE049A61835A1887419CC0D044EEE@DEWDFEMB12A.global.corp.sap> Message-ID: <52692F31.2040803@oracle.com> Hi Goetz, Thank you for looking at this code. On 10/24/2013 5:16 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > I appreciate this change a lot. > > As you touch this anyways, I would propose to rename NarrowOopHeapMax > to UnscaledOopHeapMax. Narrow is also used in contexts where scaling is > required, thus I find this is a misleading name for the 4G boundary. Ok. I made this change. I reverted the change to globalDefinitions.hpp so UnscaledOopHeapMax is in universe.cpp only. It seems to read better in the code. > > The following are my more general thoughts about this issue, not directly > to be considered by this change: > I think especially maintaining two different bases as in the current approach > is expensive. Wouldn't it be feasible to use the same base for both spaces > (oops and classes)? The class space could be placed below the base, so that > decompression requires a subtraction. This would be a bit more expensive > on platforms where shladd exists, but loading the two bases is much more > expensive. We implemented two different bases to support CDS which is independent of the Java heap and has to have a fixed address. While it's not something we have in the documentation yet, you can use CDS with -server with 64 bits. But there's a bit more work we need to do to provide a class list and with performance. But this is why we chose the 2 base approach. Also, if we add the ability to mmap more compressed class spaces, we need to mmap at higher addresses, so if the single base was between the java heap and the compressed class space, the java heap would have the subtraction. I suppose this is possible. We have to go up because solaris malloc needs lower addresses. All of the new features we talk about want to have the lower addresses too! > Alternatively one could use negative compressed classes, loading them > with sign extension. This would require that the sign bit is set, effectively > limiting the compressed class space to halve of the heap. Hmm. I don't get it. > > For big heaps one could even think of putting the class space into the > lower regions so that no base is needed. > One would end up with four configurations: > Oop space class space > Small: no base no base > Medium: no base base > Big: base no base > XXXL: base base > > This should all be compatible with extending the compressed class space. > There should be a natural upper bound to class space given the heap size, > At least (2*class space) < heap should hold. See above though, we're trying to avoid making things go in lower heap so we have space for other things we will want in the future in lower heap. Also, through benchmarking (obviously we didnt' run these ones) we found there wasn't a lot of expense with the second base. The change I really wanted to do is have a near-class/far-class implementation and we can put the near classes in lower heap in a much smaller space. And the near classes are fixed size. The prototype I did, where near-class was just a pointer to Klass, had 8% performance regression with javac and would probably be slower with these nashorn tests too. But they had some nice properties where you could predict the size of the class metaspace from number of classes, didn't interact with the CDS address (only pointers to what we stored in CDS), and didn't fragment. The main performance problem I had was with compiler calls through vtables, which we are supposed to avoid and I should measure that prototype against these tests. Thank you for the thoughts and comments. Coleen > 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: Donnerstag, 24. Oktober 2013 06:04 > To: hotspot-dev Source Developers > Subject: RFR: 8024927: Nashorn performance regression with CompressedOops > > Summary: Allocate compressed class space at end of Java heap. For small > heap sizes, without CDS, reserve some space under 32G so compressed > classes can have the same (more favorable) compression algorithm as oops. > > This change may have to be reverted when we implement extending > compressed class spaces in the future, but it gets back the performance > of these nashorn benchmarks, and seems to make sense for small heaps. > > open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ > bug link https://bugs.openjdk.java.net/browse/JDK-8024927 > > Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 > solaris/x64 and windows/x64 (in progress). Also running refworkload. > > Thanks, > Coleen From gerard.ziemski at oracle.com Thu Oct 24 07:51:22 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 24 Oct 2013 09:51:22 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) Message-ID: <526933EA.1000604@oracle.com> Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks) Description: On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns 128 pages for both main (primodial, primary - ie. the one created by the OS itself) and secondary threads, when in fact 2048 pages are available for the main thread. pthread_get_stacksize_np() correctly returns 2048 pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X versions. An issue has been filed with Apple, but in the meantime we need to substitute 2048 pages whenever pthread_get_stacksize_np() returns anything else (ie. 128) on main thread. The workaround is only active if the kernel version shows we are running on 10.9 or later (the workaround will have to be modified once Apple fixes the issue) The workaround uses hardcoded value of 2048 pages for main thread, because: 1. The correct value can in fact be found at runtime using signals (please see my test case attached to the bug's JDK issue), however, such code needs signal handlers and also takes about 3.5 ms, so it's probably not a viable solution. 2. According to https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html that's the size of the main thread for OS X. Testing: Issue's own test, UTE vm.quick and nsk.stack References: http://cr.openjdk.java.net/~hseigel/8020753/ https://bugs.openjdk.java.net/browse/JDK-8020753 cheers From daniel.daugherty at oracle.com Thu Oct 24 08:57:27 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Oct 2013 09:57:27 -0600 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <526933EA.1000604@oracle.com> References: <526933EA.1000604@oracle.com> Message-ID: <52694367.2030708@oracle.com> > http://cr.openjdk.java.net/~hseigel/8020753/ src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp line 86: # include line 87: #define DEFAULT_MAIN_THREAD_STACK_PAGES 2048 line 88: #define OS_X_10_9_0_KERNEL_MAJOR_VERSION 13 Since you indented 'include', to be consistent you should also indent 'define' on lines 87-88. line 843: if ((*size) < (DEFAULT_MAIN_THREAD_STACK_PAGES*(size_t)getpagesize())) { line 849: *size = (DEFAULT_MAIN_THREAD_STACK_PAGES*getpagesize()); Please add spaces around multiplication ('*') operators. line 848: if (atoi(kern_osrelease) >= OS_X_10_9_0_KERNEL_MAJOR_VERSION) { Please add a comment like this above line 848: // atoi() will ignore the minor and micro portions of the version string Looks great. Thumbs up! Dan On 10/24/13 8:51 AM, Gerard Ziemski wrote: > Please review this proposed workaround (round 2) for OS X 10.9 > (Mavericks) > > Description: > > On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API > returns 128 pages for both main (primodial, primary - ie. the one > created by the OS itself) and secondary threads, when in fact 2048 > pages are available for the main thread. pthread_get_stacksize_np() > correctly returns 2048 pages for main thread on 10.8, 10.7, 10.6 and > probably all previous OS X versions. > > An issue has been filed with Apple, but in the meantime we need to > substitute 2048 pages whenever pthread_get_stacksize_np() returns > anything else (ie. 128) on main thread. The workaround is only active > if the kernel version shows we are running on 10.9 or later (the > workaround will have to be modified once Apple fixes the issue) > > The workaround uses hardcoded value of 2048 pages for main thread, > because: > > 1. The correct value can in fact be found at runtime using signals > (please see my test case attached to the bug's JDK issue), however, > such code needs signal handlers and also takes about 3.5 ms, so it's > probably not a viable solution. > > 2. According to > https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html > that's the size of the main thread for OS X. > > > Testing: > > Issue's own test, UTE vm.quick and nsk.stack > > > References: > > http://cr.openjdk.java.net/~hseigel/8020753/ > > https://bugs.openjdk.java.net/browse/JDK-8020753 > > > cheers > From gerard.ziemski at oracle.com Thu Oct 24 09:49:21 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 24 Oct 2013 11:49:21 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <52694367.2030708@oracle.com> References: <526933EA.1000604@oracle.com> <52694367.2030708@oracle.com> Message-ID: <52694F91.8040600@oracle.com> Will do. Thanks Dan! On 10/24/2013 10:57 AM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~hseigel/8020753/ > > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > line 86: # include > line 87: #define DEFAULT_MAIN_THREAD_STACK_PAGES 2048 > line 88: #define OS_X_10_9_0_KERNEL_MAJOR_VERSION 13 > Since you indented 'include', to be consistent you should > also indent 'define' on lines 87-88. > > line 843: if ((*size) < > (DEFAULT_MAIN_THREAD_STACK_PAGES*(size_t)getpagesize())) { > line 849: *size = > (DEFAULT_MAIN_THREAD_STACK_PAGES*getpagesize()); > Please add spaces around multiplication ('*') operators. > > line 848: if (atoi(kern_osrelease) >= > OS_X_10_9_0_KERNEL_MAJOR_VERSION) { > Please add a comment like this above line 848: > // atoi() will ignore the minor and micro portions of the > version string > > Looks great. Thumbs up! > > Dan > > > On 10/24/13 8:51 AM, Gerard Ziemski wrote: >> Please review this proposed workaround (round 2) for OS X 10.9 >> (Mavericks) >> >> Description: >> >> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API >> returns 128 pages for both main (primodial, primary - ie. the one >> created by the OS itself) and secondary threads, when in fact 2048 >> pages are available for the main thread. pthread_get_stacksize_np() >> correctly returns 2048 pages for main thread on 10.8, 10.7, 10.6 and >> probably all previous OS X versions. >> >> An issue has been filed with Apple, but in the meantime we need to >> substitute 2048 pages whenever pthread_get_stacksize_np() returns >> anything else (ie. 128) on main thread. The workaround is only active >> if the kernel version shows we are running on 10.9 or later (the >> workaround will have to be modified once Apple fixes the issue) >> >> The workaround uses hardcoded value of 2048 pages for main thread, >> because: >> >> 1. The correct value can in fact be found at runtime using signals >> (please see my test case attached to the bug's JDK issue), however, >> such code needs signal handlers and also takes about 3.5 ms, so it's >> probably not a viable solution. >> >> 2. According to >> https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html >> that's the size of the main thread for OS X. >> >> >> Testing: >> >> Issue's own test, UTE vm.quick and nsk.stack >> >> >> References: >> >> http://cr.openjdk.java.net/~hseigel/8020753/ >> >> https://bugs.openjdk.java.net/browse/JDK-8020753 >> >> >> cheers >> > > > From igor.veresov at oracle.com Thu Oct 24 09:49:32 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 24 Oct 2013 09:49:32 -0700 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <526933EA.1000604@oracle.com> References: <526933EA.1000604@oracle.com> Message-ID: <89D6ABAB-FCE3-4C41-9463-74044867743E@oracle.com> Looks good to me. igor On Oct 24, 2013, at 7:51 AM, Gerard Ziemski wrote: > Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks) > > Description: > > On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns 128 pages for both main (primodial, primary - ie. the one created by the OS itself) and secondary threads, when in fact 2048 pages are available for the main thread. pthread_get_stacksize_np() correctly returns 2048 pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X versions. > > An issue has been filed with Apple, but in the meantime we need to substitute 2048 pages whenever pthread_get_stacksize_np() returns anything else (ie. 128) on main thread. The workaround is only active if the kernel version shows we are running on 10.9 or later (the workaround will have to be modified once Apple fixes the issue) > > The workaround uses hardcoded value of 2048 pages for main thread, because: > > 1. The correct value can in fact be found at runtime using signals (please see my test case attached to the bug's JDK issue), however, such code needs signal handlers and also takes about 3.5 ms, so it's probably not a viable solution. > > 2. According to https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html that's the size of the main thread for OS X. > > > Testing: > > Issue's own test, UTE vm.quick and nsk.stack > > > References: > > http://cr.openjdk.java.net/~hseigel/8020753/ > https://bugs.openjdk.java.net/browse/JDK-8020753 > > > cheers > From gerard.ziemski at oracle.com Thu Oct 24 09:51:19 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 24 Oct 2013 11:51:19 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <89D6ABAB-FCE3-4C41-9463-74044867743E@oracle.com> References: <526933EA.1000604@oracle.com> <89D6ABAB-FCE3-4C41-9463-74044867743E@oracle.com> Message-ID: <52695007.1000804@oracle.com> Thank you Igor! On 10/24/2013 11:49 AM, Igor Veresov wrote: > Looks good to me. > > igor > > On Oct 24, 2013, at 7:51 AM, Gerard Ziemski wrote: > >> Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks) >> >> Description: >> >> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns 128 pages for both main (primodial, primary - ie. the one created by the OS itself) and secondary threads, when in fact 2048 pages are available for the main thread. pthread_get_stacksize_np() correctly returns 2048 pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X versions. >> >> An issue has been filed with Apple, but in the meantime we need to substitute 2048 pages whenever pthread_get_stacksize_np() returns anything else (ie. 128) on main thread. The workaround is only active if the kernel version shows we are running on 10.9 or later (the workaround will have to be modified once Apple fixes the issue) >> >> The workaround uses hardcoded value of 2048 pages for main thread, because: >> >> 1. The correct value can in fact be found at runtime using signals (please see my test case attached to the bug's JDK issue), however, such code needs signal handlers and also takes about 3.5 ms, so it's probably not a viable solution. >> >> 2. According to https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html that's the size of the main thread for OS X. >> >> >> Testing: >> >> Issue's own test, UTE vm.quick and nsk.stack >> >> >> References: >> >> http://cr.openjdk.java.net/~hseigel/8020753/ >> https://bugs.openjdk.java.net/browse/JDK-8020753 >> >> >> cheers >> > > From volker.simonis at gmail.com Thu Oct 24 10:46:15 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 24 Oct 2013 19:46:15 +0200 Subject: JDK-6890703: dtrace.o causes linker warnings Message-ID: Hi, we always get linker warnings like: Linking vm... ld: warning: symbol `Universe::_narrow_oop' has differing types: (file universe.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol `Universe::_methodKlassObj' has differing types: (file universe.o type=OBJT; file dtrace.o type=FUNC); when compiling the HotSpot on Solaris. I just found that there already exists a bug for this issue: "JDK-6890703: dtrace.o causes linker warnings" (https://bugs.openjdk.java.net/browse/JDK-6890703) but unfortunately no solution. I also found out, that this problem is related to newer dtrace versions. Taking the following 'extern.d' dtrace program: extern UseCompressedOops; dtrace:helper: { this->done = ``UseCompressedOops; } and compiling it with '/usr/sbin/dtrace -64 -D_LP64 -C -I. -G -xlazyload -o /tmp/dtrace.o -s extern.d' results in following object files: For dtrace: Sun D 1.4.1 [Index] Value Size Type Bind Other Shndx Name [2] | 0| 2009|OBJT |GLOB |0 |2 |___SUNW_dof [1] | 0| 0|FUNC |GLOB |0 |UNDEF |UseCompressedOops but for dtrace: Sun D 1.1 [Index] Value Size Type Bind Other Shndx Name [2] | 0| 2007|OBJT |GLOB |0 |2 |___SUNW_dof [1] | 0| 0|NOTY |GLOB |0 |UNDEF |UseCompressedOops So the newer dtrace makes the external reference to ' UseCompressedOops' of type 'FUNC' which conflicts with HotSpot's definition of UseCompressedOops' and results in a warning. On the other hand, the old version of dtrace makes the external reference to be of type 'NOTY' which doesn't seem to bother the linker. I have no idea if this behaviour can be influenced (e.g. by giving the externel reference the right type in D). Is there any DTrace wizard out there who knows how this can be fixed? Thank you and best regards, Volker From vladimir.danushevsky at oracle.com Thu Oct 24 14:18:28 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 24 Oct 2013 21:18:28 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20131024211843.5309D62702@hg.openjdk.java.net> Changeset: f9d4ed6c88dd Author: dholmes Date: 2013-10-21 20:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9d4ed6c88dd 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Reviewed-by: sla, sspitsyn ! test/TEST.groups Changeset: 8cd1abf3ecab Author: dholmes Date: 2013-10-21 21:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8cd1abf3ecab Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 2036c97e3af0 Author: dholmes Date: 2013-10-21 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2036c97e3af0 Merge From david.holmes at oracle.com Thu Oct 24 15:59:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Oct 2013 08:59:45 +1000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> Message-ID: <5269A661.1080807@oracle.com> David, In src/share/native/java/lang/java_props.h the new field should really also be in ifdef MACOSX. The change to System.c allays my concerns there. You can also consider the hotspot changes Reviewed. Thanks, David H. On 24/10/2013 1:52 PM, David DeHaven wrote: > >>>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >>> >>> I like this idea. But it needs testing. >> >> Cool, I'll poke at it when I get a chance. > > Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. > > It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. > > I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... > > > Updated (hopefully final...) webrev: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ > > Changes from last version: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html > > (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) > > > As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). > > -DrD- > From david.dehaven at oracle.com Thu Oct 24 16:05:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 24 Oct 2013 16:05:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5269A661.1080807@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> <5269A661.1080807@oracle.com> Message-ID: <0825B755-E580-486B-A509-17037425D2FE@oracle.com> > David, > > In src/share/native/java/lang/java_props.h the new field should really also be in ifdef MACOSX. It's inside the "#ifdef MACOSX" block that was already there (starts at line 94), that's why I moved it to the bottom. You can't see it in the xDIFFs, but it's visible in the side-by-side frame mode. > The change to System.c allays my concerns there. > > You can also consider the hotspot changes Reviewed. Thank you! -DrD- From calvin.cheung at oracle.com Thu Oct 24 16:21:19 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Thu, 24 Oct 2013 23:21:19 +0000 Subject: hg: hsx/hotspot-main/hotspot: 20 new changesets Message-ID: <20131024232201.230AB6270C@hg.openjdk.java.net> Changeset: 7fe6ef09d242 Author: farvidsson Date: 2013-10-16 09:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7fe6ef09d242 8025638: jmap returns 0 instead of 1 when it fails. Summary: Re-factored some code handling return values and fails/errors during tool execution. Reviewed-by: sla, kevinw Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 042cf42c72bd Author: simonis Date: 2013-10-16 15:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/042cf42c72bd 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Reviewed-by: sla, kamg ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceTypes.xsl Changeset: d248425bcfe8 Author: hseigel Date: 2013-10-16 14:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d248425bcfe8 8024804: Crash when InterfaceMethodref resolves to Object.registerNatives Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods. Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8024804/RegisterNatives.java Changeset: 9e0ef3f02648 Author: hseigel Date: 2013-10-16 15:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9e0ef3f02648 Merge Changeset: 1bee3014cf2a Author: dsamersoff Date: 2013-10-17 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1bee3014cf2a 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Summary: Coredump store memsz elf field rounded up to page Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ffb471203842 Author: erikj Date: 2013-10-17 16:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ffb471203842 8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! make/windows/makefiles/trace.make Changeset: ad8e901ca2e1 Author: sla Date: 2013-10-17 12:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ad8e901ca2e1 Merge Changeset: d2db09f281ca Author: dsamersoff Date: 2013-10-17 16:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d2db09f281ca 8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime. Serviceability agent support was updated for this data Reviewed-by: coleenp, minqi, sla Contributed-by: eric.mccorkle at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b942ac65ac86 Author: dsamersoff Date: 2013-10-17 17:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b942ac65ac86 Merge Changeset: d0453d2fd045 Author: dsamersoff Date: 2013-10-18 10:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0453d2fd045 Merge Changeset: ee99e1a7c5fb Author: ccheung Date: 2013-10-18 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ee99e1a7c5fb Merge ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 996d1f2f056f Author: dsamersoff Date: 2013-10-19 21:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/996d1f2f056f 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 1327b7f85503 Author: ccheung Date: 2013-10-21 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1327b7f85503 Merge Changeset: 662c154d2749 Author: hseigel Date: 2013-10-22 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/662c154d2749 8026394: Eclipse fails with JDK8 build 111 Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object. With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE. Reviewed-by: acorn, dholmes Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8026394/InterfaceObjectTest.java Changeset: b8860472c377 Author: iklam Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b8860472c377 8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread Summary: Revert changes in JDK-8008962 Reviewed-by: coleenp, sspitsyn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 28be4c586b70 Author: iklam Date: 2013-10-22 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/28be4c586b70 Merge Changeset: a997d762fa20 Author: hseigel Date: 2013-10-22 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a997d762fa20 8026809: [TESTBUG] Create regression test for JDK-8026041 Summary: Created simple regression test for the bug Reviewed-by: hseigel, lfoltan, zgu Contributed-by: mikhailo.seledtsov at oracle.com + test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java Changeset: c183576a2dd1 Author: hseigel Date: 2013-10-22 22:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c183576a2dd1 Merge Changeset: b658cfe35857 Author: farvidsson Date: 2013-10-23 10:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b658cfe35857 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Summary: Fixes a bug with vmArgs when using JDKToolLauncher Reviewed-by: sla, dholmes ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: b3a4d4279fa3 Author: ccheung Date: 2013-10-24 17:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b3a4d4279fa3 Merge From coleen.phillimore at oracle.com Thu Oct 24 18:13:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Oct 2013 21:13:25 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52691EBB.50103@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> Message-ID: <5269C5B5.5000103@oracle.com> Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops I've updated the code to resolve the issues that Stefan found and implemented suggestions from Stefan and Goetz. I did additional testing and added a test. Please review again. http://cr.openjdk.java.net/~coleenp/8024927_2/ Thanks, Coleen On 10/24/2013 9:20 AM, Stefan Karlsson wrote: > On 10/24/13 3:01 PM, Coleen Phillimore wrote: >> >> Stefan, >> >> Thank you for the quick code review and testing. >> >> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>> Summary: Allocate compressed class space at end of Java heap. For >>>> small heap sizes, without CDS, reserve some space under 32G so >>>> compressed classes can have the same (more favorable) compression >>>> algorithm as oops. >>>> >>>> This change may have to be reverted when we implement extending >>>> compressed class spaces in the future, but it gets back the >>>> performance of these nashorn benchmarks, and seems to make sense >>>> for small heaps. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>> >>> Hi Coleen, >>> >>> If I you run with a small heap, say -Xmx128m, you get shifted >>> compressed klass pointers. Is that intentional? >>> >>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>> >>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>> Compressed Oops, 32-bits Oops >>> >>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>> Compressed class space size: 1073741824 Address: 0x0000000100000000 >>> Req Addr: 0x0000000100000000 >>> >> >> The top address 0x0000000100000000 + size must require the shift, >> since the base is zero (ie, the code did this math). > > Sure. But do we want the top address to be 0x0000000100000000 when we > probably could fit both heap and the compressed class space in the > lower 4GB? But let's ignore that for this change. > >>> >>> Some comments: >>> >>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>> >>> >>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>> LogKlassAlignmentInBytes; >>> >>> Shouldn't you be using this constant: ? >>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + >>> 1) << LogKlassAlignmentInBytes; >>> >> >> Yes, it's the same constant as NarrowOopHeapMax so I made it common. >> I guess the name is confusing so I reverted that bit of the change >> and have a copy of the constant in the code. > > OK. I'll check the new webrev. > >> >>> >>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>> LogKlassAlignmentInBytes; >>> 2819 // If compressed class space fits in lower 32G, we don't need >>> a base. >>> 2820 if (higher_address <= (address)klass_encoding_max) { >>> 2821 Universe::set_narrow_klass_base(0); >>> 2822 lower_base = 0; // effectively lower base is zero. >>> 2823 } else { >>> 2824 Universe::set_narrow_klass_base(lower_base); >>> 2825 } >>> 2826 >>> 2827 if ((uint64_t)(higher_address - lower_base) < >>> (uint64_t)max_juint) { >>> 2828 Universe::set_narrow_klass_shift(0); >>> 2829 } else { >>> 2830 assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces"); >>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>> 2832 } >>> >>> If you execute line 2822, will you hit the assert at line 2830 if >>> you run with CDS and set SharedBaseAddress. >>> >>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>> ... >>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>> ... >> >> I hadn't completely excluded UseSharedSpaces from this change, which >> I intended to do. I fixed this now. >> >>> >>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>> _reserve_alignment); >>> >>> Could you keep the alignment, or remove it? >> >> What do you mean? > > I mean that you messed up the indentation of _reserve_alignment. Maybe > a copy and past from the patch will show this: > assert_is_ptr_aligned(requested_addr, _reserve_alignment); > assert_is_ptr_aligned(cds_base, _reserve_alignment); > - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); > + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); > >>> >>> >>> - allocate_metaspace_compressed_klass_ptrs((char >>> *)CompressedKlassPointersBase, 0); >>> + char* base = (char*)Universe::heap()->reserved_region().end(); >>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>> >>> You need to make sure that 'base' address is aligned against >>> Metaspace::reserve_alignment(). >>> >> >> Fixed. >> >>> >>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>> >>> >>> + if (UseCompressedClassPointers && >>> + LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes) { >>> + // For small heaps, save some space for compressed >>> class pointer >>> + // space with no base, only when ObjAlignmentInBytes is >>> 64 bits. >>> + uint64_t class_space = >>> align_size_up(CompressedClassSpaceSize, alignment); >>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>> + alignment), "difference must be aligned too"); >>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>> + >>> + if (total_size <= new_top) { >>> + base = (new_top - heap_size); >>> + } else { >>> + base = (OopEncodingHeapMax - heap_size); >>> + } >>> >>> I don't understand why you have this restriction: >>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>> >> >> Because if you use a bigger ObjAlignmentInBytes, you probably have a >> bigger heap and this won't work anyway and I didn't want to support >> and test it. > > OK. Could you change the check to compare LogMinObjAlignmentInBytes to > 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? That > would be much more clear too me. > >> I am rerunning some tests on the fixes. I'll send out another webrev >> shortly. >> >> Thanks so much for breaking my code! Srsly. > > OK. I'll wait for the update. > > thanks, > StefanK >> >> Coleen >> >>> thanks, >>> StefanK >>> >>>> >>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>>> >>>> Thanks, >>>> Coleen >>> >> > From david.holmes at oracle.com Thu Oct 24 18:49:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Oct 2013 11:49:20 +1000 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <526933EA.1000604@oracle.com> References: <526933EA.1000604@oracle.com> Message-ID: <5269CE20.5080300@oracle.com> Hi Gerard, My only comment is whether the check for >= 10.9 should just be == ? Assuming they fix this for 10.10 then == would mean no need to make any future changes, whereas >= would. On the other hand if they don't fix it then we'd need to change the code again if using ==. How confident are you they will actually fix this? Was the choice of >= a deliberate one? :) Cheers, David On 25/10/2013 12:51 AM, Gerard Ziemski wrote: > Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks) > > Description: > > On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns > 128 pages for both main (primodial, primary - ie. the one created by the > OS itself) and secondary threads, when in fact 2048 pages are available > for the main thread. pthread_get_stacksize_np() correctly returns 2048 > pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X > versions. > > An issue has been filed with Apple, but in the meantime we need to > substitute 2048 pages whenever pthread_get_stacksize_np() returns > anything else (ie. 128) on main thread. The workaround is only active if > the kernel version shows we are running on 10.9 or later (the workaround > will have to be modified once Apple fixes the issue) > > The workaround uses hardcoded value of 2048 pages for main thread, because: > > 1. The correct value can in fact be found at runtime using signals > (please see my test case attached to the bug's JDK issue), however, such > code needs signal handlers and also takes about 3.5 ms, so it's probably > not a viable solution. > > 2. According to > https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html > that's the size of the main thread for OS X. > > > Testing: > > Issue's own test, UTE vm.quick and nsk.stack > > > References: > > http://cr.openjdk.java.net/~hseigel/8020753/ > > https://bugs.openjdk.java.net/browse/JDK-8020753 > > > cheers > From igor.veresov at oracle.com Thu Oct 24 20:07:38 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 25 Oct 2013 03:07:38 +0000 Subject: hg: hsx/hotspot-main/hotspot: 27 new changesets Message-ID: <20131025030926.C757262719@hg.openjdk.java.net> Changeset: 74e00b98d5dd Author: anoll Date: 2013-10-17 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/74e00b98d5dd 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase size for the template interpreter accordingly Reviewed-by: kvn, twisti ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: 1856ea98184a Author: adlertz Date: 2013-10-18 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1856ea98184a 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Summary: Enables private copies of inputs for recent spill copies as well Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/reg_split.cpp Changeset: e3b736cf4fa3 Author: adlertz Date: 2013-10-18 09:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3b736cf4fa3 Merge Changeset: 252d541466ea Author: morris Date: 2013-10-18 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/252d541466ea 8008242: VerifyOops is broken on SPARC Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3213ba4d3dff Author: roland Date: 2013-10-19 12:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3213ba4d3dff 8024069: replace_in_map() should operate on parent maps Summary: type information gets lost because replace_in_map() doesn't update parent maps Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.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/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 19c5a042b0b3 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19c5a042b0b3 8026414: [TESTBUG] Tests for Tiered/NonTiered levels Reviewed-by: twisti, iveresov + test/compiler/tiered/CompLevelsTest.java + test/compiler/tiered/NonTieredLevelsTest.java + test/compiler/tiered/TieredLevelsTest.java Changeset: 600c83f8e6a5 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/600c83f8e6a5 8023318: compiler/whitebox tests timeout with enabled TieredCompilation Reviewed-by: kvn, twisti ! test/compiler/whitebox/CompilerWhiteBoxTest.java Changeset: e842cc2d2dfb Author: iveresov Date: 2013-10-19 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e842cc2d2dfb Merge Changeset: 52575a17a36c Author: iignatyev Date: 2013-10-21 09:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/52575a17a36c 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Reviewed-by: twisti, iveresov ! test/compiler/print/PrintInlining.java Changeset: 4748b3308cda Author: iveresov Date: 2013-10-21 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4748b3308cda Merge Changeset: 5ccbab1c69f3 Author: roland Date: 2013-10-22 09:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ccbab1c69f3 8026251: New type profiling points: parameters to methods Summary: x86 interpreter and c1 type profiling for parameters on method entries Reviewed-by: kvn, twisti ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp + src/cpu/x86/vm/interp_masm_x86.cpp + src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: 435c7b4577cd Author: rbackman Date: 2013-10-21 15:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/435c7b4577cd 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Reviewed-by: iveresov, roland ! src/share/vm/opto/compile.cpp Changeset: 36e17466dd39 Author: rbackman Date: 2013-10-22 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/36e17466dd39 Merge Changeset: 8b4bbba322d3 Author: anoll Date: 2013-10-23 10:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b4bbba322d3 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper() Reviewed-by: roland, iveresov ! src/share/vm/compiler/compileBroker.cpp Changeset: b2ee5dc63353 Author: roland Date: 2013-10-23 12:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2ee5dc63353 8024070: C2 needs some form of type speculation Summary: record unused type profile information with type system, propagate and use it. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.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/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp + test/compiler/types/TypeSpeculation.java Changeset: 4c9115774c8e Author: adlertz Date: 2013-10-23 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c9115774c8e 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor Reviewed-by: roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 97d400662426 Author: adlertz Date: 2013-10-23 19:22 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/97d400662426 Merge Changeset: 9acbfe04b5c3 Author: iveresov Date: 2013-10-23 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9acbfe04b5c3 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator Reviewed-by: twisti, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 1c90f0072f0d Author: twisti Date: 2013-10-23 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1c90f0072f0d 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3a04e444da6d Author: iveresov Date: 2013-10-23 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a04e444da6d Merge Changeset: 59e8ad757e19 Author: rbackman Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59e8ad757e19 8026844: Various Math functions needs intrinsification Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/AddExactICondTest.java + test/compiler/intrinsics/mathexact/AddExactIConstantTest.java + test/compiler/intrinsics/mathexact/AddExactILoadTest.java + test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java + test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java + test/compiler/intrinsics/mathexact/AddExactLConstantTest.java + test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/DecExactITest.java + test/compiler/intrinsics/mathexact/DecExactLTest.java + test/compiler/intrinsics/mathexact/IncExactITest.java + test/compiler/intrinsics/mathexact/IncExactLTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactICondTest.java + test/compiler/intrinsics/mathexact/MulExactIConstantTest.java + test/compiler/intrinsics/mathexact/MulExactILoadTest.java + test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java + test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java + test/compiler/intrinsics/mathexact/MulExactLConstantTest.java + test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactIConstantTest.java + test/compiler/intrinsics/mathexact/NegExactILoadTest.java + test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java + test/compiler/intrinsics/mathexact/SubExactICondTest.java + test/compiler/intrinsics/mathexact/SubExactIConstantTest.java + test/compiler/intrinsics/mathexact/SubExactILoadTest.java + test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java + test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java + test/compiler/intrinsics/mathexact/SubExactLConstantTest.java + test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java Changeset: 68f07c29521b Author: anoll Date: 2013-10-15 08:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/68f07c29521b 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Summary: Remove duplicate print Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: d95eca175eff Author: sspitsyn Date: 2013-10-23 20:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d95eca175eff 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose ! src/share/vm/prims/methodHandles.cpp Changeset: 0d1661d63d70 Author: vlivanov Date: 2013-10-23 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0d1661d63d70 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: f7d928a3181c Author: roland Date: 2013-10-24 19:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f7d928a3181c 8026978: JSR292: fatal error: Type profiling not implemented on this platform Summary: force TypeProfileLevel to 0 on non x86 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp Changeset: 395499125cb0 Author: iveresov Date: 2013-10-24 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/395499125cb0 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 6b32b911d723 Author: iveresov Date: 2013-10-24 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b32b911d723 Merge ! src/share/vm/runtime/vmStructs.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java From stefan.karlsson at oracle.com Fri Oct 25 01:25:29 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 25 Oct 2013 10:25:29 +0200 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <5269C5B5.5000103@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269C5B5.5000103@oracle.com> Message-ID: <526A2AF9.8010402@oracle.com> On 2013-10-25 03:13, Coleen Phillimore wrote: > Summary: Allocate compressed class space at end of Java heap. For > small heap sizes, without CDS, save some space so compressed classes > can have the same favorable compression as oops > > I've updated the code to resolve the issues that Stefan found and > implemented suggestions from Stefan and Goetz. I did additional > testing and added a test. Please review again. > > http://cr.openjdk.java.net/~coleenp/8024927_2/ You set up the narrow_klass_max as 4GB (32 bits): 2817 const uint64_t narrow_klass_max = (uint64_t(max_juint) + 1); Are the following usages of (uint64_t)max_juint wrong? 2827 if ((uint64_t)(higher_address - lower_base) < (uint64_t)max_juint) { 2843 return ((uint64_t)(higher_address - lower_base) < (uint64_t)max_juint); 3007 if (cds_total + compressed_class_space_size() > (uint64_t)max_juint) { Should they be changed to: 2827 if ((uint64_t)(higher_address - lower_base) <= ((uint64_t)max_juint + 1)) { 2843 return ((uint64_t)(higher_address - lower_base) <= ((uint64_t)max_juint + 1)); 3007 if (cds_total + compressed_class_space_size() > ((uint64_t)max_juint + 1)) { Or rather: 2827 if ((uint64_t)(higher_address - lower_base) <= narrow_klass_max) { 2843 return ((uint64_t)(higher_address - lower_base) <= narrow_klass_max); 3007 if (cds_total + compressed_class_space_size() > narrow_klass_max) { thanks, StefanK > > Thanks, > Coleen > > On 10/24/2013 9:20 AM, Stefan Karlsson wrote: >> On 10/24/13 3:01 PM, Coleen Phillimore wrote: >>> >>> Stefan, >>> >>> Thank you for the quick code review and testing. >>> >>> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>>> Summary: Allocate compressed class space at end of Java heap. For >>>>> small heap sizes, without CDS, reserve some space under 32G so >>>>> compressed classes can have the same (more favorable) compression >>>>> algorithm as oops. >>>>> >>>>> This change may have to be reverted when we implement extending >>>>> compressed class spaces in the future, but it gets back the >>>>> performance of these nashorn benchmarks, and seems to make sense >>>>> for small heaps. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>>> >>>> Hi Coleen, >>>> >>>> If I you run with a small heap, say -Xmx128m, you get shifted >>>> compressed klass pointers. Is that intentional? >>>> >>>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>>> >>>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>>> Compressed Oops, 32-bits Oops >>>> >>>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>>> Compressed class space size: 1073741824 Address: 0x0000000100000000 >>>> Req Addr: 0x0000000100000000 >>>> >>> >>> The top address 0x0000000100000000 + size must require the shift, >>> since the base is zero (ie, the code did this math). >> >> Sure. But do we want the top address to be 0x0000000100000000 when we >> probably could fit both heap and the compressed class space in the >> lower 4GB? But let's ignore that for this change. >> >>>> >>>> Some comments: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>>> >>>> >>>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>>> LogKlassAlignmentInBytes; >>>> >>>> Shouldn't you be using this constant: ? >>>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + >>>> 1) << LogKlassAlignmentInBytes; >>>> >>> >>> Yes, it's the same constant as NarrowOopHeapMax so I made it >>> common. I guess the name is confusing so I reverted that bit of the >>> change and have a copy of the constant in the code. >> >> OK. I'll check the new webrev. >> >>> >>>> >>>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>>> LogKlassAlignmentInBytes; >>>> 2819 // If compressed class space fits in lower 32G, we don't >>>> need a base. >>>> 2820 if (higher_address <= (address)klass_encoding_max) { >>>> 2821 Universe::set_narrow_klass_base(0); >>>> 2822 lower_base = 0; // effectively lower base is zero. >>>> 2823 } else { >>>> 2824 Universe::set_narrow_klass_base(lower_base); >>>> 2825 } >>>> 2826 >>>> 2827 if ((uint64_t)(higher_address - lower_base) < >>>> (uint64_t)max_juint) { >>>> 2828 Universe::set_narrow_klass_shift(0); >>>> 2829 } else { >>>> 2830 assert(!UseSharedSpaces, "Cannot shift with >>>> UseSharedSpaces"); >>>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>>> 2832 } >>>> >>>> If you execute line 2822, will you hit the assert at line 2830 if >>>> you run with CDS and set SharedBaseAddress. >>>> >>>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>> ... >>>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>> ... >>> >>> I hadn't completely excluded UseSharedSpaces from this change, which >>> I intended to do. I fixed this now. >>> >>>> >>>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>>> _reserve_alignment); >>>> >>>> Could you keep the alignment, or remove it? >>> >>> What do you mean? >> >> I mean that you messed up the indentation of _reserve_alignment. >> Maybe a copy and past from the patch will show this: >> assert_is_ptr_aligned(requested_addr, _reserve_alignment); >> assert_is_ptr_aligned(cds_base, _reserve_alignment); >> - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); >> + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); >> >>>> >>>> >>>> - allocate_metaspace_compressed_klass_ptrs((char >>>> *)CompressedKlassPointersBase, 0); >>>> + char* base = >>>> (char*)Universe::heap()->reserved_region().end(); >>>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>>> >>>> You need to make sure that 'base' address is aligned against >>>> Metaspace::reserve_alignment(). >>>> >>> >>> Fixed. >>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>>> >>>> >>>> + if (UseCompressedClassPointers && >>>> + LogMinObjAlignmentInBytes == >>>> LogKlassAlignmentInBytes) { >>>> + // For small heaps, save some space for compressed >>>> class pointer >>>> + // space with no base, only when ObjAlignmentInBytes >>>> is 64 bits. >>>> + uint64_t class_space = >>>> align_size_up(CompressedClassSpaceSize, alignment); >>>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>> + alignment), "difference must be aligned too"); >>>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>>> + >>>> + if (total_size <= new_top) { >>>> + base = (new_top - heap_size); >>>> + } else { >>>> + base = (OopEncodingHeapMax - heap_size); >>>> + } >>>> >>>> I don't understand why you have this restriction: >>>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>>> >>> >>> Because if you use a bigger ObjAlignmentInBytes, you probably have a >>> bigger heap and this won't work anyway and I didn't want to support >>> and test it. >> >> OK. Could you change the check to compare LogMinObjAlignmentInBytes >> to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? >> That would be much more clear too me. >> >>> I am rerunning some tests on the fixes. I'll send out another >>> webrev shortly. >>> >>> Thanks so much for breaking my code! Srsly. >> >> OK. I'll wait for the update. >> >> thanks, >> StefanK >>> >>> Coleen >>> >>>> thanks, >>>> StefanK >>>> >>>>> >>>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From goetz.lindenmaier at sap.com Fri Oct 25 05:22:21 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 25 Oct 2013 12:22:21 +0000 Subject: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <52692F31.2040803@oracle.com> References: <52689C1A.8040305@oracle.com> <4295855A5C1DE049A61835A1887419CC0D044EEE@DEWDFEMB12A.global.corp.sap> <52692F31.2040803@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D0453D1@DEWDFEMB12A.global.corp.sap> Hi Colleen, thanks a lot for the extensive explanations and adopting that name! > We implemented two different bases to support CDS which is independent > of the Java heap and has to have a fixed address. While it's not > something we have in the documentation yet, you can use CDS with -server > with 64 bits. But there's a bit more work we need to do to provide a > class list and with performance. But this is why we chose the 2 base > approach. OK, I understand. But the VM should know that it runs with CDS, and could choose a common base if running without. But well, that increases the test-space even more. > Also, if we add the ability to mmap more compressed class spaces, we > need to mmap at higher addresses, so if the single base was between the > java heap and the compressed class space, the java heap would have the > subtraction. I suppose this is possible. We have to go up because > solaris malloc needs lower addresses. All of the new features we talk > about want to have the lower addresses too! No, you definitely don't want the subtraction for oops (if there is shladd or the like). > > Alternatively one could use negative compressed classes, loading them > > with sign extension. This would require that the sign bit is set, effectively > > limiting the compressed class space to halve of the heap. > Hmm. I don't get it. Compressed oops are treated as 32-bit positive offsets. They are loaded as unsigned ints (zero extended) and then added to the base. You could treat the compressed klasses as singed ints, load them signextended and then add them to the base. If only negative ints are used, this addresses the part before the base. But there are only 2g negative (signed) offset, while there are 4g positive ones. On sparc you would use ldsw for compressed classes, lduw for compressed oops. I think there would be enough space for extending the compressed class space to higher addresses, if you layout the spaces like this (assuming shift 3): 0 base-16G base base+32G |------------|xxxxxx------------|xxxxxxxxxxxxxxxxxxxxxxx-------|-------------------... /|\ /|\ /|\ | | | klass space | heap space to extend klass space > See above though, we're trying to avoid making things go in lower heap > so we have space for other things we will want in the future in lower > heap. Also, through benchmarking (obviously we didnt' run these ones) > we found there wasn't a lot of expense with the second base. I understand. I'll benchmark the two variants once I implemented your change on PPC. Maybe it really makes no big difference. If the compressed classes compete with other spaces for the lower bits also benchmarking will have to make the decision, I guess. Thanks for all the comments! Best regards, Goetz. From gerard.ziemski at oracle.com Fri Oct 25 06:58:54 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 25 Oct 2013 08:58:54 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <5269CE20.5080300@oracle.com> References: <526933EA.1000604@oracle.com> <5269CE20.5080300@oracle.com> Message-ID: <526A791E.9080903@oracle.com> Yes it was a deliberate choice: Using == would be a time bomb if Apple failed to fix it post 10.9 (would have to be reactive action) Using >= means we do things on our own terms as the workaround is harmless even on well behaved system, so we don't have to rush to change the code, unless we want to (is proactive action) cheers On 10/24/2013 8:49 PM, David Holmes wrote: > Hi Gerard, > > My only comment is whether the check for >= 10.9 should just be == ? > Assuming they fix this for 10.10 then == would mean no need to make > any future changes, whereas >= would. On the other hand if they don't > fix it then we'd need to change the code again if using ==. > > How confident are you they will actually fix this? Was the choice of > >= a deliberate one? :) > > Cheers, > David > > On 25/10/2013 12:51 AM, Gerard Ziemski wrote: >> Please review this proposed workaround (round 2) for OS X 10.9 >> (Mavericks) >> >> Description: >> >> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns >> 128 pages for both main (primodial, primary - ie. the one created by the >> OS itself) and secondary threads, when in fact 2048 pages are available >> for the main thread. pthread_get_stacksize_np() correctly returns 2048 >> pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X >> versions. >> >> An issue has been filed with Apple, but in the meantime we need to >> substitute 2048 pages whenever pthread_get_stacksize_np() returns >> anything else (ie. 128) on main thread. The workaround is only active if >> the kernel version shows we are running on 10.9 or later (the workaround >> will have to be modified once Apple fixes the issue) >> >> The workaround uses hardcoded value of 2048 pages for main thread, >> because: >> >> 1. The correct value can in fact be found at runtime using signals >> (please see my test case attached to the bug's JDK issue), however, such >> code needs signal handlers and also takes about 3.5 ms, so it's probably >> not a viable solution. >> >> 2. According to >> https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html >> >> that's the size of the main thread for OS X. >> >> >> Testing: >> >> Issue's own test, UTE vm.quick and nsk.stack >> >> >> References: >> >> http://cr.openjdk.java.net/~hseigel/8020753/ >> >> https://bugs.openjdk.java.net/browse/JDK-8020753 >> >> >> cheers >> > From coleen.phillimore at oracle.com Fri Oct 25 07:20:42 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Oct 2013 10:20:42 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <526A2AF9.8010402@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269C5B5.5000103@oracle.com> <526A2AF9.8010402@oracle.com> Message-ID: <526A7E3A.9020704@oracle.com> On 10/25/2013 4:25 AM, Stefan Karlsson wrote: > > On 2013-10-25 03:13, Coleen Phillimore wrote: >> Summary: Allocate compressed class space at end of Java heap. For >> small heap sizes, without CDS, save some space so compressed classes >> can have the same favorable compression as oops >> >> I've updated the code to resolve the issues that Stefan found and >> implemented suggestions from Stefan and Goetz. I did additional >> testing and added a test. Please review again. >> >> http://cr.openjdk.java.net/~coleenp/8024927_2/ > > You set up the narrow_klass_max as 4GB (32 bits): > 2817 const uint64_t narrow_klass_max = (uint64_t(max_juint) + 1); > > Are the following usages of (uint64_t)max_juint wrong? Yes, they should all be +1. I've introduced constant UnscaledClassSpaceMax to match the similar constant with the same value in universe.cpp (UnscaledOopHeapMax - name suggested by Goetz) and replaced the uses. Thanks, Coleen > 2827 if ((uint64_t)(higher_address - lower_base) < > (uint64_t)max_juint) { > > 2843 return ((uint64_t)(higher_address - lower_base) < > (uint64_t)max_juint); > > 3007 if (cds_total + compressed_class_space_size() > > (uint64_t)max_juint) { > > Should they be changed to: > 2827 if ((uint64_t)(higher_address - lower_base) <= > ((uint64_t)max_juint + 1)) { > > 2843 return ((uint64_t)(higher_address - lower_base) <= > ((uint64_t)max_juint + 1)); > > 3007 if (cds_total + compressed_class_space_size() > > ((uint64_t)max_juint + 1)) { > > Or rather: > 2827 if ((uint64_t)(higher_address - lower_base) <= narrow_klass_max) { > > 2843 return ((uint64_t)(higher_address - lower_base) <= > narrow_klass_max); > > 3007 if (cds_total + compressed_class_space_size() > > narrow_klass_max) { > > thanks, > StefanK > >> >> Thanks, >> Coleen >> >> On 10/24/2013 9:20 AM, Stefan Karlsson wrote: >>> On 10/24/13 3:01 PM, Coleen Phillimore wrote: >>>> >>>> Stefan, >>>> >>>> Thank you for the quick code review and testing. >>>> >>>> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>>>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>>>> Summary: Allocate compressed class space at end of Java heap. >>>>>> For small heap sizes, without CDS, reserve some space under 32G >>>>>> so compressed classes can have the same (more favorable) >>>>>> compression algorithm as oops. >>>>>> >>>>>> This change may have to be reverted when we implement extending >>>>>> compressed class spaces in the future, but it gets back the >>>>>> performance of these nashorn benchmarks, and seems to make sense >>>>>> for small heaps. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>>>> >>>>> Hi Coleen, >>>>> >>>>> If I you run with a small heap, say -Xmx128m, you get shifted >>>>> compressed klass pointers. Is that intentional? >>>>> >>>>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>>>> >>>>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>>>> Compressed Oops, 32-bits Oops >>>>> >>>>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>>>> Compressed class space size: 1073741824 Address: >>>>> 0x0000000100000000 Req Addr: 0x0000000100000000 >>>>> >>>> >>>> The top address 0x0000000100000000 + size must require the shift, >>>> since the base is zero (ie, the code did this math). >>> >>> Sure. But do we want the top address to be 0x0000000100000000 when >>> we probably could fit both heap and the compressed class space in >>> the lower 4GB? But let's ignore that for this change. >>> >>>>> >>>>> Some comments: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>>>> >>>>> >>>>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>> LogKlassAlignmentInBytes; >>>>> >>>>> Shouldn't you be using this constant: ? >>>>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + >>>>> 1) << LogKlassAlignmentInBytes; >>>>> >>>> >>>> Yes, it's the same constant as NarrowOopHeapMax so I made it >>>> common. I guess the name is confusing so I reverted that bit of >>>> the change and have a copy of the constant in the code. >>> >>> OK. I'll check the new webrev. >>> >>>> >>>>> >>>>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>> LogKlassAlignmentInBytes; >>>>> 2819 // If compressed class space fits in lower 32G, we don't >>>>> need a base. >>>>> 2820 if (higher_address <= (address)klass_encoding_max) { >>>>> 2821 Universe::set_narrow_klass_base(0); >>>>> 2822 lower_base = 0; // effectively lower base is zero. >>>>> 2823 } else { >>>>> 2824 Universe::set_narrow_klass_base(lower_base); >>>>> 2825 } >>>>> 2826 >>>>> 2827 if ((uint64_t)(higher_address - lower_base) < >>>>> (uint64_t)max_juint) { >>>>> 2828 Universe::set_narrow_klass_shift(0); >>>>> 2829 } else { >>>>> 2830 assert(!UseSharedSpaces, "Cannot shift with >>>>> UseSharedSpaces"); >>>>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>>>> 2832 } >>>>> >>>>> If you execute line 2822, will you hit the assert at line 2830 if >>>>> you run with CDS and set SharedBaseAddress. >>>>> >>>>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>> ... >>>>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>> ... >>>> >>>> I hadn't completely excluded UseSharedSpaces from this change, >>>> which I intended to do. I fixed this now. >>>> >>>>> >>>>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>>>> _reserve_alignment); >>>>> >>>>> Could you keep the alignment, or remove it? >>>> >>>> What do you mean? >>> >>> I mean that you messed up the indentation of _reserve_alignment. >>> Maybe a copy and past from the patch will show this: >>> assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>> assert_is_ptr_aligned(cds_base, _reserve_alignment); >>> - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); >>> + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); >>> >>>>> >>>>> >>>>> - allocate_metaspace_compressed_klass_ptrs((char >>>>> *)CompressedKlassPointersBase, 0); >>>>> + char* base = >>>>> (char*)Universe::heap()->reserved_region().end(); >>>>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>>>> >>>>> You need to make sure that 'base' address is aligned against >>>>> Metaspace::reserve_alignment(). >>>>> >>>> >>>> Fixed. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>>>> >>>>> >>>>> + if (UseCompressedClassPointers && >>>>> + LogMinObjAlignmentInBytes == >>>>> LogKlassAlignmentInBytes) { >>>>> + // For small heaps, save some space for compressed >>>>> class pointer >>>>> + // space with no base, only when ObjAlignmentInBytes >>>>> is 64 bits. >>>>> + uint64_t class_space = >>>>> align_size_up(CompressedClassSpaceSize, alignment); >>>>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>>> + alignment), "difference must be aligned too"); >>>>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>>>> + >>>>> + if (total_size <= new_top) { >>>>> + base = (new_top - heap_size); >>>>> + } else { >>>>> + base = (OopEncodingHeapMax - heap_size); >>>>> + } >>>>> >>>>> I don't understand why you have this restriction: >>>>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>>>> >>>> >>>> Because if you use a bigger ObjAlignmentInBytes, you probably have >>>> a bigger heap and this won't work anyway and I didn't want to >>>> support and test it. >>> >>> OK. Could you change the check to compare LogMinObjAlignmentInBytes >>> to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? >>> That would be much more clear too me. >>> >>>> I am rerunning some tests on the fixes. I'll send out another >>>> webrev shortly. >>>> >>>> Thanks so much for breaking my code! Srsly. >>> >>> OK. I'll wait for the update. >>> >>> thanks, >>> StefanK >>>> >>>> Coleen >>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>>>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Fri Oct 25 08:55:10 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 25 Oct 2013 17:55:10 +0200 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Message-ID: <1828254.FSQ7MTpyjg@mgerdin03> Hi all, Initially I'd like to hear people's opinions on this issue. It appears to have surfaced after we've reduced the unnecessary alignment "cushions" for metaspace together with the fact that we are now always able to use the very last bit of a VirtualSpace (in Metaspace). The issue is extremely difficult to reproduce, because it relies on the exact order and size of all metaspace allocations for a run to trigger this problem. Description of the problem: We recently had some mysterious crashes in the GC testing, and I narrowed them down to the following scenario: Imagine that we have a VirtualSpace (for Metaspace) [ | bb] ConstMethod And that the very last object allocated in such a space is a ConstMethod, and that it has its embedded bytecodes filling up to the very end. Consider the case when the second last bytecode (the one before "Xreturn") is one with an embedded 2-byte index (a constant pool or local variable index) for example: - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - (bcp+4) UNMAPPED MEMORY The template interpreter here uses a 4-byte load on intel to read the index embedded in the checkcast: mov 0x1(%esi),%ebx this will read the bytes [bcp+1,bcp+4] and cause a SEGV. I looked through the code for places where we do similar loads of 2-byte indexes and found the same problem for iload_w: 0xe73f7fbb: mov 0x2(%esi),%ebx 0xe73f7fbe: bswap %ebx 0xe73f7fc0: shr $0x10,%ebx I looked through most places where we emit __ movl __ bswap and changed the places I could find which were affected. Suggested fix: Replace movl with load_[un]signed_short in the places where we load 2-byte values from the byte code stream. I've verified that load_unsigned_short (which boils down to movzwl, opcodes 0x0f 0xb7 only reads 2 bytes). Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ Testing: vm.quick.testlist -Xint on linux-i586 and x86_64(running) Thanks /Mikael From christian.thalinger at oracle.com Fri Oct 25 09:25:47 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 25 Oct 2013 09:25:47 -0700 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <1828254.FSQ7MTpyjg@mgerdin03> References: <1828254.FSQ7MTpyjg@mgerdin03> Message-ID: <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> Good catch. Is there a similar issue on SPARC? On Oct 25, 2013, at 8:55 AM, Mikael Gerdin wrote: > Hi all, > > Initially I'd like to hear people's opinions on this issue. It appears to have > surfaced after we've reduced the unnecessary alignment "cushions" for > metaspace together with the fact that we are now always able to use the very > last bit of a VirtualSpace (in Metaspace). > > The issue is extremely difficult to reproduce, because it relies on the exact > order and size of all metaspace allocations for a run to trigger this problem. > > Description of the problem: > > We recently had some mysterious crashes in the GC testing, and I narrowed them > down to the following scenario: > > Imagine that we have a VirtualSpace (for Metaspace) > [ | bb] > ConstMethod > > And that the very last object allocated in such a space is a ConstMethod, and > that it has its embedded bytecodes filling up to the very end. > > Consider the case when the second last bytecode (the one before "Xreturn") is > one with an embedded 2-byte index (a constant pool or local variable index) > for example: > - (bcp) checkcast #6 0xc0 0x00 0x06 > - (bcp+3) areturn 0xb0 > - (bcp+4) UNMAPPED MEMORY > > The template interpreter here uses a 4-byte load on intel to read the index > embedded in the checkcast: > mov 0x1(%esi),%ebx > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > > I looked through the code for places where we do similar loads of 2-byte > indexes and found the same problem for iload_w: > 0xe73f7fbb: mov 0x2(%esi),%ebx > 0xe73f7fbe: bswap %ebx > 0xe73f7fc0: shr $0x10,%ebx > > I looked through most places where we emit > __ movl > __ bswap > and changed the places I could find which were affected. > > Suggested fix: > Replace movl with load_[un]signed_short in the places where we load 2-byte > values from the byte code stream. > I've verified that load_unsigned_short (which boils down to movzwl, opcodes > 0x0f 0xb7 only reads 2 bytes). > > Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 > Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ > > Testing: > vm.quick.testlist -Xint on linux-i586 and x86_64(running) > > Thanks > /Mikael From mikael.gerdin at oracle.com Fri Oct 25 09:46:39 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 25 Oct 2013 18:46:39 +0200 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> Message-ID: <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> On 25 October 2013 18:25:47 Christian Thalinger wrote: > Good catch. Is there a similar issue on SPARC? I looked through the other platforms, they all seem to do single-byte loads for the indices. On SPARC I suppose it's because it can't do unaligned multibyte loads. /Mikael > > On Oct 25, 2013, at 8:55 AM, Mikael Gerdin wrote: > > > Hi all, > > Initially I'd like to hear people's opinions on this issue. It appears to > have surfaced after we've reduced the unnecessary alignment "cushions" for > metaspace together with the fact that we are now always able to use the > very last bit of a VirtualSpace (in Metaspace). > > The issue is extremely difficult to reproduce, because it relies on the > exact order and size of all metaspace allocations for a run to trigger this > problem. > > Description of the problem: > > We recently had some mysterious crashes in the GC testing, and I narrowed > them down to the following scenario: > > Imagine that we have a VirtualSpace (for Metaspace) > > [ | bb] > > ConstMethod > > And that the very last object allocated in such a space is a ConstMethod, > and that it has its embedded bytecodes filling up to the very end. > > Consider the case when the second last bytecode (the one before > "Xreturn") is one with an embedded 2-byte index (a constant pool or local > variable index) for example: > > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - (bcp+4) > UNMAPPED MEMORY > > The template interpreter here uses a 4-byte load on intel to read the > index embedded in the checkcast: > > mov 0x1(%esi),%ebx > > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > > I looked through the code for places where we do similar loads of 2-byte > indexes and found the same problem for iload_w: > > 0xe73f7fbb: mov 0x2(%esi),%ebx > > 0xe73f7fbe: bswap %ebx > > 0xe73f7fc0: shr $0x10,%ebx > > I looked through most places where we emit > > __ movl > > __ bswap > > and changed the places I could find which were affected. > > Suggested fix: > > Replace movl with load_[un]signed_short in the places where we load > 2-byte values from the byte code stream. > > I've verified that load_unsigned_short (which boils down to movzwl, > opcodes 0x0f 0xb7 only reads 2 bytes). > > Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ > > Testing: > > vm.quick.testlist -Xint on linux-i586 and x86_64(running) > > Thanks > > /Mikael > From igor.veresov at oracle.com Fri Oct 25 10:21:28 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Oct 2013 10:21:28 -0700 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <526A791E.9080903@oracle.com> References: <526933EA.1000604@oracle.com> <5269CE20.5080300@oracle.com> <526A791E.9080903@oracle.com> Message-ID: <2C12124D-FB47-41A8-AE31-ABB7FF733C0A@oracle.com> Hopefully the fix will be in the next update (probably the minor one) and then we can put an upper bound on the version that need this hack. Which would probably require parsing the minor version digits. igor On Oct 25, 2013, at 6:58 AM, Gerard Ziemski wrote: > Yes it was a deliberate choice: > > Using == would be a time bomb if Apple failed to fix it post 10.9 (would have to be reactive action) > > Using >= means we do things on our own terms as the workaround is harmless even on well behaved system, so we don't have to rush to change the code, unless we want to (is proactive action) > > > cheers > > On 10/24/2013 8:49 PM, David Holmes wrote: >> Hi Gerard, >> >> My only comment is whether the check for >= 10.9 should just be == ? Assuming they fix this for 10.10 then == would mean no need to make any future changes, whereas >= would. On the other hand if they don't fix it then we'd need to change the code again if using ==. >> >> How confident are you they will actually fix this? Was the choice of >= a deliberate one? :) >> >> Cheers, >> David >> >> On 25/10/2013 12:51 AM, Gerard Ziemski wrote: >>> Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks) >>> >>> Description: >>> >>> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns >>> 128 pages for both main (primodial, primary - ie. the one created by the >>> OS itself) and secondary threads, when in fact 2048 pages are available >>> for the main thread. pthread_get_stacksize_np() correctly returns 2048 >>> pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X >>> versions. >>> >>> An issue has been filed with Apple, but in the meantime we need to >>> substitute 2048 pages whenever pthread_get_stacksize_np() returns >>> anything else (ie. 128) on main thread. The workaround is only active if >>> the kernel version shows we are running on 10.9 or later (the workaround >>> will have to be modified once Apple fixes the issue) >>> >>> The workaround uses hardcoded value of 2048 pages for main thread, because: >>> >>> 1. The correct value can in fact be found at runtime using signals >>> (please see my test case attached to the bug's JDK issue), however, such >>> code needs signal handlers and also takes about 3.5 ms, so it's probably >>> not a viable solution. >>> >>> 2. According to >>> https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html >>> that's the size of the main thread for OS X. >>> >>> >>> Testing: >>> >>> Issue's own test, UTE vm.quick and nsk.stack >>> >>> >>> References: >>> >>> http://cr.openjdk.java.net/~hseigel/8020753/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8020753 >>> >>> >>> cheers >>> >> > From gerard.ziemski at oracle.com Fri Oct 25 11:19:58 2013 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 25 Oct 2013 13:19:58 -0500 Subject: RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2) In-Reply-To: <2C12124D-FB47-41A8-AE31-ABB7FF733C0A@oracle.com> References: <526933EA.1000604@oracle.com> <5269CE20.5080300@oracle.com> <526A791E.9080903@oracle.com> <2C12124D-FB47-41A8-AE31-ABB7FF733C0A@oracle.com> Message-ID: <526AB64E.2060408@oracle.com> That's the plan. On 10/25/2013 12:21 PM, Igor Veresov wrote: > Hopefully the fix will be in the next update (probably the minor one) and then we can put an upper bound on the version that need this hack. Which would probably require parsing the minor version digits. > > igor > > On Oct 25, 2013, at 6:58 AM, Gerard Ziemski wrote: > >> Yes it was a deliberate choice: >> >> Using == would be a time bomb if Apple failed to fix it post 10.9 (would have to be reactive action) >> >> Using >= means we do things on our own terms as the workaround is harmless even on well behaved system, so we don't have to rush to change the code, unless we want to (is proactive action) >> >> >> cheers >> >> On 10/24/2013 8:49 PM, David Holmes wrote: >>> Hi Gerard, >>> >>> My only comment is whether the check for >= 10.9 should just be == ? Assuming they fix this for 10.10 then == would mean no need to make any future changes, whereas >= would. On the other hand if they don't fix it then we'd need to change the code again if using ==. >>> >>> How confident are you they will actually fix this? Was the choice of >= a deliberate one? :) >>> >>> Cheers, >>> David >>> >>> On 25/10/2013 12:51 AM, Gerard Ziemski wrote: >>>> Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks) >>>> >>>> Description: >>>> >>>> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API returns >>>> 128 pages for both main (primodial, primary - ie. the one created by the >>>> OS itself) and secondary threads, when in fact 2048 pages are available >>>> for the main thread. pthread_get_stacksize_np() correctly returns 2048 >>>> pages for main thread on 10.8, 10.7, 10.6 and probably all previous OS X >>>> versions. >>>> >>>> An issue has been filed with Apple, but in the meantime we need to >>>> substitute 2048 pages whenever pthread_get_stacksize_np() returns >>>> anything else (ie. 128) on main thread. The workaround is only active if >>>> the kernel version shows we are running on 10.9 or later (the workaround >>>> will have to be modified once Apple fixes the issue) >>>> >>>> The workaround uses hardcoded value of 2048 pages for main thread, because: >>>> >>>> 1. The correct value can in fact be found at runtime using signals >>>> (please see my test case attached to the bug's JDK issue), however, such >>>> code needs signal handlers and also takes about 3.5 ms, so it's probably >>>> not a viable solution. >>>> >>>> 2. According to >>>> https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html >>>> that's the size of the main thread for OS X. >>>> >>>> >>>> Testing: >>>> >>>> Issue's own test, UTE vm.quick and nsk.stack >>>> >>>> >>>> References: >>>> >>>> http://cr.openjdk.java.net/~hseigel/8020753/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8020753 >>>> >>>> >>>> cheers >>>> > > From coleen.phillimore at oracle.com Fri Oct 25 11:33:07 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Oct 2013 14:33:07 -0400 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Message-ID: <526AB963.10305@oracle.com> Mikael, This is really good work! Thank you for narrowing this down from the core file because we were going to have a lot of trouble reproducing this. The code changes look good but why do you still need the bswapl and shrl? Doesn't load_unsigned_short load the value without sign extending also? I'm only guessing what bswapl does from the context though. void TemplateTable::locals_index_wide(Register reg) { - __ movl(reg, at_bcp(2)); + __ load_unsigned_short(reg, at_bcp(2)); __ bswapl(reg); __ shrl(reg, 16); __ negptr(reg); } Thanks, Coleen On 10/25/2013 12:46 PM, Mikael Gerdin wrote: > > > On 25 October 2013 18:25:47 Christian Thalinger > wrote: >> Good catch. Is there a similar issue on SPARC? > > I looked through the other platforms, they all seem to do single-byte > loads for the indices. > On SPARC I suppose it's because it can't do unaligned multibyte loads. > /Mikael > >> >> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin >> wrote: >> >> > Hi all, >> > Initially I'd like to hear people's opinions on this issue. It >> appears to have surfaced after we've reduced the unnecessary >> alignment "cushions" for metaspace together with the fact that we are >> now always able to use the very last bit of a VirtualSpace (in >> Metaspace). >> > The issue is extremely difficult to reproduce, because it relies on >> the exact order and size of all metaspace allocations for a run to >> trigger this problem. >> > Description of the problem: >> > We recently had some mysterious crashes in the GC testing, and I >> narrowed them down to the following scenario: >> > Imagine that we have a VirtualSpace (for Metaspace) >> > [ | bb] >> > ConstMethod >> > And that the very last object allocated in such a space is a >> ConstMethod, and that it has its embedded bytecodes filling up to the >> very end. >> > Consider the case when the second last bytecode (the one before >> "Xreturn") is one with an embedded 2-byte index (a constant pool or >> local variable index) for example: >> > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - >> (bcp+4) UNMAPPED MEMORY >> > The template interpreter here uses a 4-byte load on intel to read >> the index embedded in the checkcast: >> > mov 0x1(%esi),%ebx >> > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. >> > I looked through the code for places where we do similar loads of >> 2-byte indexes and found the same problem for iload_w: >> > 0xe73f7fbb: mov 0x2(%esi),%ebx >> > 0xe73f7fbe: bswap %ebx >> > 0xe73f7fc0: shr $0x10,%ebx >> > I looked through most places where we emit >> > __ movl >> > __ bswap >> > and changed the places I could find which were affected. >> > Suggested fix: >> > Replace movl with load_[un]signed_short in the places where we load >> 2-byte values from the byte code stream. >> > I've verified that load_unsigned_short (which boils down to movzwl, >> opcodes 0x0f 0xb7 only reads 2 bytes). >> > Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 >> > Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ >> > Testing: >> > vm.quick.testlist -Xint on linux-i586 and x86_64(running) >> > Thanks >> > /Mikael >> > > From mikael.gerdin at oracle.com Fri Oct 25 11:50:39 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 25 Oct 2013 20:50:39 +0200 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <526AB963.10305@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> <526AB963.10305@oracle.com> Message-ID: <141f0f43430.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Coleen, On 25 October 2013 20:33:07 Coleen Phillimore wrote: > > Mikael, > > This is really good work! Thank you for narrowing this down from the core > file because we were going to have a lot of trouble reproducing this. Thanks! > > The code changes look good but why do you still need the bswapl and shrl? > Doesn't load_unsigned_short load the value without sign extending also? > I'm only guessing what bswapl does from the context though. Since the bytecode stores big endian values we still need to convert them to native (little endian) byte order. So if we have the bytecode: checkcast #6 0xc0 0x00 0x06 After the load we end up with 0x00000600 Bswap turns this to 0x00060000 The shift gets us 0x00000006 (if someone could sanity-check this for me it would be great) /Mikael > > void TemplateTable::locals_index_wide(Register reg) { > - __ movl(reg, at_bcp(2)); > + __ load_unsigned_short(reg, at_bcp(2)); > __ bswapl(reg); > __ shrl(reg, 16); > __ negptr(reg); > } > > Thanks, > Coleen > > On 10/25/2013 12:46 PM, Mikael Gerdin wrote: > > > > > > On 25 October 2013 18:25:47 Christian Thalinger > wrote: > >> Good catch. Is there a similar issue on SPARC? > > > > I looked through the other platforms, they all seem to do single-byte > loads for the indices. > > On SPARC I suppose it's because it can't do unaligned multibyte loads. > > /Mikael > > > >> > >> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin wrote: > >> > >> > Hi all, > >> > Initially I'd like to hear people's opinions on this issue. It appears > to have surfaced after we've reduced the unnecessary alignment "cushions" > for metaspace together with the fact that we are now always able to use the > very last bit of a VirtualSpace (in Metaspace). > >> > The issue is extremely difficult to reproduce, because it relies on > the exact order and size of all metaspace allocations for a run to trigger > this problem. > >> > Description of the problem: > >> > We recently had some mysterious crashes in the GC testing, and I > narrowed them down to the following scenario: > >> > Imagine that we have a VirtualSpace (for Metaspace) > >> > [ | bb] > >> > ConstMethod > >> > And that the very last object allocated in such a space is a > ConstMethod, and that it has its embedded bytecodes filling up to the very end. > >> > Consider the case when the second last bytecode (the one before > "Xreturn") is one with an embedded 2-byte index (a constant pool or local > variable index) for example: > >> > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - (bcp+4) > UNMAPPED MEMORY > >> > The template interpreter here uses a 4-byte load on intel to read the > index embedded in the checkcast: > >> > mov 0x1(%esi),%ebx > >> > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > >> > I looked through the code for places where we do similar loads of > 2-byte indexes and found the same problem for iload_w: > >> > 0xe73f7fbb: mov 0x2(%esi),%ebx > >> > 0xe73f7fbe: bswap %ebx > >> > 0xe73f7fc0: shr $0x10,%ebx > >> > I looked through most places where we emit > >> > __ movl > >> > __ bswap > >> > and changed the places I could find which were affected. > >> > Suggested fix: > >> > Replace movl with load_[un]signed_short in the places where we load > 2-byte values from the byte code stream. > >> > I've verified that load_unsigned_short (which boils down to movzwl, > opcodes 0x0f 0xb7 only reads 2 bytes). > >> > Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 > >> > Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ > >> > Testing: > >> > vm.quick.testlist -Xint on linux-i586 and x86_64(running) > >> > Thanks > >> > /Mikael > >> > > > > > From coleen.phillimore at oracle.com Fri Oct 25 12:04:35 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Oct 2013 15:04:35 -0400 Subject: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D0453D1@DEWDFEMB12A.global.corp.sap> References: <52689C1A.8040305@oracle.com> <4295855A5C1DE049A61835A1887419CC0D044EEE@DEWDFEMB12A.global.corp.sap> <52692F31.2040803@oracle.com> <4295855A5C1DE049A61835A1887419CC0D0453D1@DEWDFEMB12A.global.corp.sap> Message-ID: <526AC0C3.1020004@oracle.com> On 10/25/2013 8:22 AM, Lindenmaier, Goetz wrote: > > Hi Colleen, > > thanks a lot for the extensive explanations and adopting that name! > Thank you for the suggestion. > > We implemented two different bases to support CDS which is independent > > > of the Java heap and has to have a fixed address. While it's not > > > something we have in the documentation yet, you can use CDS with > -server > > > with 64 bits. But there's a bit more work we need to do to provide a > > > class list and with performance. But this is why we chose the 2 base > > > approach. > > OK, I understand. But the VM should know that it runs with CDS, > > and could choose a common base if running without. But well, that > > increases the test-space even more. > We make that decision afterwards, unfortunately so there'd have to be a bit of rearrangment. > > > Also, if we add the ability to mmap more compressed class spaces, we > > > need to mmap at higher addresses, so if the single base was between the > > > java heap and the compressed class space, the java heap would have the > > > subtraction. I suppose this is possible. We have to go up because > > > solaris malloc needs lower addresses. All of the new features we talk > > > about want to have the lower addresses too! > > No, you definitely don't want the subtraction for oops (if there is > shladd or the like). > > > > Alternatively one could use negative compressed classes, loading them > > > > with sign extension. This would require that the sign bit is set, > effectively > > > > limiting the compressed class space to halve of the heap. > > >Hmm. I don't get it. > > Compressed oops are treated as 32-bit positive offsets. They are loaded > > as unsigned ints (zero extended) and then added to the base. > > You could treat the compressed klasses as singed ints, load them > > signextended and then add them to the base. If only negative > > ints are used, this addresses the part before the base. But there > > are only 2g negative (signed) offset, while there are 4g positive ones. > > On sparc you would use ldsw for compressed classes, lduw for > > compressed oops. > > I think there would be enough space for extending the compressed > > class space to higher addresses, if you layout the spaces like this > > (assuming shift 3): > > 0 base-16G base base+32G > > |------------|xxxxxx------------|xxxxxxxxxxxxxxxxxxxxxxx-------|-------------------... > > /|\ /|\ /|\ > > | | | > > klass space | heap > > space to extend > > klass space > Thanks for the picture. It helps! This would require that we always have a base, right? > > See above though, we're trying to avoid making things go in lower heap > > > so we have space for other things we will want in the future in lower > > > heap. Also, through benchmarking (obviously we didnt' run these ones) > > > we found there wasn't a lot of expense with the second base. > > I understand. I'll benchmark the two variants once I implemented your > > change on PPC. Maybe it really makes no big difference. > > If the compressed classes compete with other spaces for the lower bits > > also benchmarking will have to make the decision, I guess. > Goetz, we welcome your experimenting with this! I think there is a lot of room for new ideas. We also want to (someday) make the markOop part of the header smaller too, where in brainstorming we think we might need to allocate things in the lower 4G memory. Thanks, Coleen > Thanks for all the comments! > > Best regards, > > Goetz. > From coleen.phillimore at oracle.com Fri Oct 25 12:05:27 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Oct 2013 15:05:27 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <526A2AF9.8010402@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269C5B5.5000103@oracle.com> <526A2AF9.8010402@oracle.com> Message-ID: <526AC0F7.1030008@oracle.com> See http://cr.openjdk.java.net/~coleenp/8024927_3/ with this change. I think it looks great - thanks for the suggestion. Coleen On 10/25/2013 4:25 AM, Stefan Karlsson wrote: > > On 2013-10-25 03:13, Coleen Phillimore wrote: >> Summary: Allocate compressed class space at end of Java heap. For >> small heap sizes, without CDS, save some space so compressed classes >> can have the same favorable compression as oops >> >> I've updated the code to resolve the issues that Stefan found and >> implemented suggestions from Stefan and Goetz. I did additional >> testing and added a test. Please review again. >> >> http://cr.openjdk.java.net/~coleenp/8024927_2/ > > You set up the narrow_klass_max as 4GB (32 bits): > 2817 const uint64_t narrow_klass_max = (uint64_t(max_juint) + 1); > > Are the following usages of (uint64_t)max_juint wrong? > 2827 if ((uint64_t)(higher_address - lower_base) < > (uint64_t)max_juint) { > > 2843 return ((uint64_t)(higher_address - lower_base) < > (uint64_t)max_juint); > > 3007 if (cds_total + compressed_class_space_size() > > (uint64_t)max_juint) { > > Should they be changed to: > 2827 if ((uint64_t)(higher_address - lower_base) <= > ((uint64_t)max_juint + 1)) { > > 2843 return ((uint64_t)(higher_address - lower_base) <= > ((uint64_t)max_juint + 1)); > > 3007 if (cds_total + compressed_class_space_size() > > ((uint64_t)max_juint + 1)) { > > Or rather: > 2827 if ((uint64_t)(higher_address - lower_base) <= narrow_klass_max) { > > 2843 return ((uint64_t)(higher_address - lower_base) <= > narrow_klass_max); > > 3007 if (cds_total + compressed_class_space_size() > > narrow_klass_max) { > > thanks, > StefanK > >> >> Thanks, >> Coleen >> >> On 10/24/2013 9:20 AM, Stefan Karlsson wrote: >>> On 10/24/13 3:01 PM, Coleen Phillimore wrote: >>>> >>>> Stefan, >>>> >>>> Thank you for the quick code review and testing. >>>> >>>> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>>>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>>>> Summary: Allocate compressed class space at end of Java heap. >>>>>> For small heap sizes, without CDS, reserve some space under 32G >>>>>> so compressed classes can have the same (more favorable) >>>>>> compression algorithm as oops. >>>>>> >>>>>> This change may have to be reverted when we implement extending >>>>>> compressed class spaces in the future, but it gets back the >>>>>> performance of these nashorn benchmarks, and seems to make sense >>>>>> for small heaps. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>>>> >>>>> Hi Coleen, >>>>> >>>>> If I you run with a small heap, say -Xmx128m, you get shifted >>>>> compressed klass pointers. Is that intentional? >>>>> >>>>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>>>> >>>>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>>>> Compressed Oops, 32-bits Oops >>>>> >>>>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>>>> Compressed class space size: 1073741824 Address: >>>>> 0x0000000100000000 Req Addr: 0x0000000100000000 >>>>> >>>> >>>> The top address 0x0000000100000000 + size must require the shift, >>>> since the base is zero (ie, the code did this math). >>> >>> Sure. But do we want the top address to be 0x0000000100000000 when >>> we probably could fit both heap and the compressed class space in >>> the lower 4GB? But let's ignore that for this change. >>> >>>>> >>>>> Some comments: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>>>> >>>>> >>>>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>> LogKlassAlignmentInBytes; >>>>> >>>>> Shouldn't you be using this constant: ? >>>>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + >>>>> 1) << LogKlassAlignmentInBytes; >>>>> >>>> >>>> Yes, it's the same constant as NarrowOopHeapMax so I made it >>>> common. I guess the name is confusing so I reverted that bit of >>>> the change and have a copy of the constant in the code. >>> >>> OK. I'll check the new webrev. >>> >>>> >>>>> >>>>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>> LogKlassAlignmentInBytes; >>>>> 2819 // If compressed class space fits in lower 32G, we don't >>>>> need a base. >>>>> 2820 if (higher_address <= (address)klass_encoding_max) { >>>>> 2821 Universe::set_narrow_klass_base(0); >>>>> 2822 lower_base = 0; // effectively lower base is zero. >>>>> 2823 } else { >>>>> 2824 Universe::set_narrow_klass_base(lower_base); >>>>> 2825 } >>>>> 2826 >>>>> 2827 if ((uint64_t)(higher_address - lower_base) < >>>>> (uint64_t)max_juint) { >>>>> 2828 Universe::set_narrow_klass_shift(0); >>>>> 2829 } else { >>>>> 2830 assert(!UseSharedSpaces, "Cannot shift with >>>>> UseSharedSpaces"); >>>>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>>>> 2832 } >>>>> >>>>> If you execute line 2822, will you hit the assert at line 2830 if >>>>> you run with CDS and set SharedBaseAddress. >>>>> >>>>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>> ... >>>>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>> ... >>>> >>>> I hadn't completely excluded UseSharedSpaces from this change, >>>> which I intended to do. I fixed this now. >>>> >>>>> >>>>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>>>> _reserve_alignment); >>>>> >>>>> Could you keep the alignment, or remove it? >>>> >>>> What do you mean? >>> >>> I mean that you messed up the indentation of _reserve_alignment. >>> Maybe a copy and past from the patch will show this: >>> assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>> assert_is_ptr_aligned(cds_base, _reserve_alignment); >>> - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); >>> + assert_is_size_aligned(compressed_class_space_size(), _reserve_alignment); >>> >>>>> >>>>> >>>>> - allocate_metaspace_compressed_klass_ptrs((char >>>>> *)CompressedKlassPointersBase, 0); >>>>> + char* base = >>>>> (char*)Universe::heap()->reserved_region().end(); >>>>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>>>> >>>>> You need to make sure that 'base' address is aligned against >>>>> Metaspace::reserve_alignment(). >>>>> >>>> >>>> Fixed. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>>>> >>>>> >>>>> + if (UseCompressedClassPointers && >>>>> + LogMinObjAlignmentInBytes == >>>>> LogKlassAlignmentInBytes) { >>>>> + // For small heaps, save some space for compressed >>>>> class pointer >>>>> + // space with no base, only when ObjAlignmentInBytes >>>>> is 64 bits. >>>>> + uint64_t class_space = >>>>> align_size_up(CompressedClassSpaceSize, alignment); >>>>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>>> + alignment), "difference must be aligned too"); >>>>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>>>> + >>>>> + if (total_size <= new_top) { >>>>> + base = (new_top - heap_size); >>>>> + } else { >>>>> + base = (OopEncodingHeapMax - heap_size); >>>>> + } >>>>> >>>>> I don't understand why you have this restriction: >>>>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>>>> >>>> >>>> Because if you use a bigger ObjAlignmentInBytes, you probably have >>>> a bigger heap and this won't work anyway and I didn't want to >>>> support and test it. >>> >>> OK. Could you change the check to compare LogMinObjAlignmentInBytes >>> to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? >>> That would be much more clear too me. >>> >>>> I am rerunning some tests on the fixes. I'll send out another >>>> webrev shortly. >>>> >>>> Thanks so much for breaking my code! Srsly. >>> >>> OK. I'll wait for the update. >>> >>> thanks, >>> StefanK >>>> >>>> Coleen >>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>>>> solaris/x64 and windows/x64 (in progress). Also running refworkload. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >> > From harold.seigel at oracle.com Fri Oct 25 12:22:27 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 25 Oct 2013 15:22:27 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <526AC0F7.1030008@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269C5B5.5000103@oracle.com> <526A2AF9.8010402@oracle.com> <526AC0F7.1030008@oracle.com> Message-ID: <526AC4F3.3000906@oracle.com> Hi Coleen, Your changes look good. Thanks, Harold On 10/25/2013 3:05 PM, Coleen Phillimore wrote: > > See http://cr.openjdk.java.net/~coleenp/8024927_3/ > with this change. I > think it looks great - thanks for the suggestion. > > Coleen > > On 10/25/2013 4:25 AM, Stefan Karlsson wrote: >> >> On 2013-10-25 03:13, Coleen Phillimore wrote: >>> Summary: Allocate compressed class space at end of Java heap. For >>> small heap sizes, without CDS, save some space so compressed classes >>> can have the same favorable compression as oops >>> >>> I've updated the code to resolve the issues that Stefan found and >>> implemented suggestions from Stefan and Goetz. I did additional >>> testing and added a test. Please review again. >>> >>> http://cr.openjdk.java.net/~coleenp/8024927_2/ >> >> You set up the narrow_klass_max as 4GB (32 bits): >> 2817 const uint64_t narrow_klass_max = (uint64_t(max_juint) + 1); >> >> Are the following usages of (uint64_t)max_juint wrong? >> 2827 if ((uint64_t)(higher_address - lower_base) < >> (uint64_t)max_juint) { >> >> 2843 return ((uint64_t)(higher_address - lower_base) < >> (uint64_t)max_juint); >> >> 3007 if (cds_total + compressed_class_space_size() > >> (uint64_t)max_juint) { >> >> Should they be changed to: >> 2827 if ((uint64_t)(higher_address - lower_base) <= >> ((uint64_t)max_juint + 1)) { >> >> 2843 return ((uint64_t)(higher_address - lower_base) <= >> ((uint64_t)max_juint + 1)); >> >> 3007 if (cds_total + compressed_class_space_size() > >> ((uint64_t)max_juint + 1)) { >> >> Or rather: >> 2827 if ((uint64_t)(higher_address - lower_base) <= >> narrow_klass_max) { >> >> 2843 return ((uint64_t)(higher_address - lower_base) <= >> narrow_klass_max); >> >> 3007 if (cds_total + compressed_class_space_size() > >> narrow_klass_max) { >> >> thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>> On 10/24/2013 9:20 AM, Stefan Karlsson wrote: >>>> On 10/24/13 3:01 PM, Coleen Phillimore wrote: >>>>> >>>>> Stefan, >>>>> >>>>> Thank you for the quick code review and testing. >>>>> >>>>> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>>>>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>>>>> Summary: Allocate compressed class space at end of Java heap. >>>>>>> For small heap sizes, without CDS, reserve some space under 32G >>>>>>> so compressed classes can have the same (more favorable) >>>>>>> compression algorithm as oops. >>>>>>> >>>>>>> This change may have to be reverted when we implement extending >>>>>>> compressed class spaces in the future, but it gets back the >>>>>>> performance of these nashorn benchmarks, and seems to make sense >>>>>>> for small heaps. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>>>>> >>>>>> Hi Coleen, >>>>>> >>>>>> If I you run with a small heap, say -Xmx128m, you get shifted >>>>>> compressed klass pointers. Is that intentional? >>>>>> >>>>>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>>>>> >>>>>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>>>>> Compressed Oops, 32-bits Oops >>>>>> >>>>>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>>>>> Compressed class space size: 1073741824 Address: >>>>>> 0x0000000100000000 Req Addr: 0x0000000100000000 >>>>>> >>>>> >>>>> The top address 0x0000000100000000 + size must require the shift, >>>>> since the base is zero (ie, the code did this math). >>>> >>>> Sure. But do we want the top address to be 0x0000000100000000 when >>>> we probably could fit both heap and the compressed class space in >>>> the lower 4GB? But let's ignore that for this change. >>>> >>>>>> >>>>>> Some comments: >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>>>>> >>>>>> >>>>>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>>> LogKlassAlignmentInBytes; >>>>>> >>>>>> Shouldn't you be using this constant: ? >>>>>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) >>>>>> + 1) << LogKlassAlignmentInBytes; >>>>>> >>>>> >>>>> Yes, it's the same constant as NarrowOopHeapMax so I made it >>>>> common. I guess the name is confusing so I reverted that bit of >>>>> the change and have a copy of the constant in the code. >>>> >>>> OK. I'll check the new webrev. >>>> >>>>> >>>>>> >>>>>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>>> LogKlassAlignmentInBytes; >>>>>> 2819 // If compressed class space fits in lower 32G, we don't >>>>>> need a base. >>>>>> 2820 if (higher_address <= (address)klass_encoding_max) { >>>>>> 2821 Universe::set_narrow_klass_base(0); >>>>>> 2822 lower_base = 0; // effectively lower base is zero. >>>>>> 2823 } else { >>>>>> 2824 Universe::set_narrow_klass_base(lower_base); >>>>>> 2825 } >>>>>> 2826 >>>>>> 2827 if ((uint64_t)(higher_address - lower_base) < >>>>>> (uint64_t)max_juint) { >>>>>> 2828 Universe::set_narrow_klass_shift(0); >>>>>> 2829 } else { >>>>>> 2830 assert(!UseSharedSpaces, "Cannot shift with >>>>>> UseSharedSpaces"); >>>>>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>>>>> 2832 } >>>>>> >>>>>> If you execute line 2822, will you hit the assert at line 2830 if >>>>>> you run with CDS and set SharedBaseAddress. >>>>>> >>>>>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>>> ... >>>>>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>>> ... >>>>> >>>>> I hadn't completely excluded UseSharedSpaces from this change, >>>>> which I intended to do. I fixed this now. >>>>> >>>>>> >>>>>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>>>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>>>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>>>>> _reserve_alignment); >>>>>> >>>>>> Could you keep the alignment, or remove it? >>>>> >>>>> What do you mean? >>>> >>>> I mean that you messed up the indentation of _reserve_alignment. >>>> Maybe a copy and past from the patch will show this: >>>> assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>> assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>> - assert_is_size_aligned(class_metaspace_size(), _reserve_alignment); >>>> + assert_is_size_aligned(compressed_class_space_size(), >>>> _reserve_alignment); >>>> >>>>>> >>>>>> >>>>>> - allocate_metaspace_compressed_klass_ptrs((char >>>>>> *)CompressedKlassPointersBase, 0); >>>>>> + char* base = >>>>>> (char*)Universe::heap()->reserved_region().end(); >>>>>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>>>>> >>>>>> You need to make sure that 'base' address is aligned against >>>>>> Metaspace::reserve_alignment(). >>>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>>>>> >>>>>> >>>>>> + if (UseCompressedClassPointers && >>>>>> + LogMinObjAlignmentInBytes == >>>>>> LogKlassAlignmentInBytes) { >>>>>> + // For small heaps, save some space for compressed >>>>>> class pointer >>>>>> + // space with no base, only when ObjAlignmentInBytes >>>>>> is 64 bits. >>>>>> + uint64_t class_space = >>>>>> align_size_up(CompressedClassSpaceSize, alignment); >>>>>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>>>> + alignment), "difference must be aligned too"); >>>>>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>>>>> + >>>>>> + if (total_size <= new_top) { >>>>>> + base = (new_top - heap_size); >>>>>> + } else { >>>>>> + base = (OopEncodingHeapMax - heap_size); >>>>>> + } >>>>>> >>>>>> I don't understand why you have this restriction: >>>>>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>>>>> >>>>> >>>>> Because if you use a bigger ObjAlignmentInBytes, you probably have >>>>> a bigger heap and this won't work anyway and I didn't want to >>>>> support and test it. >>>> >>>> OK. Could you change the check to compare LogMinObjAlignmentInBytes >>>> to 3, or ObjAlignmentInBytes to 8, or OopEncodingHeapMax to 32GB? >>>> That would be much more clear too me. >>>> >>>>> I am rerunning some tests on the fixes. I'll send out another >>>>> webrev shortly. >>>>> >>>>> Thanks so much for breaking my code! Srsly. >>>> >>>> OK. I'll wait for the update. >>>> >>>> thanks, >>>> StefanK >>>>> >>>>> Coleen >>>>> >>>>>> thanks, >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>>>>> solaris/x64 and windows/x64 (in progress). Also running >>>>>>> refworkload. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Oct 25 12:28:30 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Oct 2013 15:28:30 -0400 Subject: RFR: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <526AC4F3.3000906@oracle.com> References: <52689C1A.8040305@oracle.com> <5268DE46.7050109@oracle.com> <52691A3D.30409@oracle.com> <52691EBB.50103@oracle.com> <5269C5B5.5000103@oracle.com> <526A2AF9.8010402@oracle.com> <526AC0F7.1030008@oracle.com> <526AC4F3.3000906@oracle.com> Message-ID: <526AC65E.6060500@oracle.com> On 10/25/2013 3:22 PM, harold seigel wrote: > Hi Coleen, > > Your changes look good. Thanks Harold, and thanks for the offline help. Coleen > > Thanks, Harold > > On 10/25/2013 3:05 PM, Coleen Phillimore wrote: >> >> See http://cr.openjdk.java.net/~coleenp/8024927_3/ >> with this change. >> I think it looks great - thanks for the suggestion. >> >> Coleen >> >> On 10/25/2013 4:25 AM, Stefan Karlsson wrote: >>> >>> On 2013-10-25 03:13, Coleen Phillimore wrote: >>>> Summary: Allocate compressed class space at end of Java heap. For >>>> small heap sizes, without CDS, save some space so compressed >>>> classes can have the same favorable compression as oops >>>> >>>> I've updated the code to resolve the issues that Stefan found and >>>> implemented suggestions from Stefan and Goetz. I did additional >>>> testing and added a test. Please review again. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8024927_2/ >>> >>> You set up the narrow_klass_max as 4GB (32 bits): >>> 2817 const uint64_t narrow_klass_max = (uint64_t(max_juint) + 1); >>> >>> Are the following usages of (uint64_t)max_juint wrong? >>> 2827 if ((uint64_t)(higher_address - lower_base) < >>> (uint64_t)max_juint) { >>> >>> 2843 return ((uint64_t)(higher_address - lower_base) < >>> (uint64_t)max_juint); >>> >>> 3007 if (cds_total + compressed_class_space_size() > >>> (uint64_t)max_juint) { >>> >>> Should they be changed to: >>> 2827 if ((uint64_t)(higher_address - lower_base) <= >>> ((uint64_t)max_juint + 1)) { >>> >>> 2843 return ((uint64_t)(higher_address - lower_base) <= >>> ((uint64_t)max_juint + 1)); >>> >>> 3007 if (cds_total + compressed_class_space_size() > >>> ((uint64_t)max_juint + 1)) { >>> >>> Or rather: >>> 2827 if ((uint64_t)(higher_address - lower_base) <= >>> narrow_klass_max) { >>> >>> 2843 return ((uint64_t)(higher_address - lower_base) <= >>> narrow_klass_max); >>> >>> 3007 if (cds_total + compressed_class_space_size() > >>> narrow_klass_max) { >>> >>> thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 10/24/2013 9:20 AM, Stefan Karlsson wrote: >>>>> On 10/24/13 3:01 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Stefan, >>>>>> >>>>>> Thank you for the quick code review and testing. >>>>>> >>>>>> On 10/24/2013 4:45 AM, Stefan Karlsson wrote: >>>>>>> On 10/24/13 6:03 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Allocate compressed class space at end of Java heap. >>>>>>>> For small heap sizes, without CDS, reserve some space under 32G >>>>>>>> so compressed classes can have the same (more favorable) >>>>>>>> compression algorithm as oops. >>>>>>>> >>>>>>>> This change may have to be reverted when we implement extending >>>>>>>> compressed class spaces in the future, but it gets back the >>>>>>>> performance of these nashorn benchmarks, and seems to make >>>>>>>> sense for small heaps. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/ >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8024927 >>>>>>> >>>>>>> Hi Coleen, >>>>>>> >>>>>>> If I you run with a small heap, say -Xmx128m, you get shifted >>>>>>> compressed klass pointers. Is that intentional? >>>>>>> >>>>>>> $ java -Xmx128m -XX:+PrintCompressedOopsMode -version >>>>>>> >>>>>>> heap address: 0x00000000f8000000, size: 128 MB, zero based >>>>>>> Compressed Oops, 32-bits Oops >>>>>>> >>>>>>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 >>>>>>> Compressed class space size: 1073741824 Address: >>>>>>> 0x0000000100000000 Req Addr: 0x0000000100000000 >>>>>>> >>>>>> >>>>>> The top address 0x0000000100000000 + size must require the shift, >>>>>> since the base is zero (ie, the code did this math). >>>>> >>>>> Sure. But do we want the top address to be 0x0000000100000000 when >>>>> we probably could fit both heap and the compressed class space in >>>>> the lower 4GB? But let's ignore that for this change. >>>>> >>>>>>> >>>>>>> Some comments: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> + uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>>>> LogKlassAlignmentInBytes; >>>>>>> >>>>>>> Shouldn't you be using this constant: ? >>>>>>> const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) >>>>>>> + 1) << LogKlassAlignmentInBytes; >>>>>>> >>>>>> >>>>>> Yes, it's the same constant as NarrowOopHeapMax so I made it >>>>>> common. I guess the name is confusing so I reverted that bit of >>>>>> the change and have a copy of the constant in the code. >>>>> >>>>> OK. I'll check the new webrev. >>>>> >>>>>> >>>>>>> >>>>>>> 2818 uint64_t klass_encoding_max = NarrowOopHeapMax << >>>>>>> LogKlassAlignmentInBytes; >>>>>>> 2819 // If compressed class space fits in lower 32G, we don't >>>>>>> need a base. >>>>>>> 2820 if (higher_address <= (address)klass_encoding_max) { >>>>>>> 2821 Universe::set_narrow_klass_base(0); >>>>>>> 2822 lower_base = 0; // effectively lower base is zero. >>>>>>> 2823 } else { >>>>>>> 2824 Universe::set_narrow_klass_base(lower_base); >>>>>>> 2825 } >>>>>>> 2826 >>>>>>> 2827 if ((uint64_t)(higher_address - lower_base) < >>>>>>> (uint64_t)max_juint) { >>>>>>> 2828 Universe::set_narrow_klass_shift(0); >>>>>>> 2829 } else { >>>>>>> 2830 assert(!UseSharedSpaces, "Cannot shift with >>>>>>> UseSharedSpaces"); >>>>>>> 2831 Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes); >>>>>>> 2832 } >>>>>>> >>>>>>> If you execute line 2822, will you hit the assert at line 2830 >>>>>>> if you run with CDS and set SharedBaseAddress. >>>>>>> >>>>>>> $ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g >>>>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>>>> ... >>>>>>> $ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g >>>>>>> -XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version >>>>>>> ... >>>>>> >>>>>> I hadn't completely excluded UseSharedSpaces from this change, >>>>>> which I intended to do. I fixed this now. >>>>>> >>>>>>> >>>>>>> 2852 assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>>>>> 2853 assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>>>>> 2854 assert_is_size_aligned(compressed_class_space_size(), >>>>>>> _reserve_alignment); >>>>>>> >>>>>>> Could you keep the alignment, or remove it? >>>>>> >>>>>> What do you mean? >>>>> >>>>> I mean that you messed up the indentation of _reserve_alignment. >>>>> Maybe a copy and past from the patch will show this: >>>>> assert_is_ptr_aligned(requested_addr, _reserve_alignment); >>>>> assert_is_ptr_aligned(cds_base, _reserve_alignment); >>>>> - assert_is_size_aligned(class_metaspace_size(), >>>>> _reserve_alignment); >>>>> + assert_is_size_aligned(compressed_class_space_size(), >>>>> _reserve_alignment); >>>>> >>>>>>> >>>>>>> >>>>>>> - allocate_metaspace_compressed_klass_ptrs((char >>>>>>> *)CompressedKlassPointersBase, 0); >>>>>>> + char* base = >>>>>>> (char*)Universe::heap()->reserved_region().end(); >>>>>>> + allocate_metaspace_compressed_klass_ptrs(base, 0); >>>>>>> >>>>>>> You need to make sure that 'base' address is aligned against >>>>>>> Metaspace::reserve_alignment(). >>>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> + if (UseCompressedClassPointers && >>>>>>> + LogMinObjAlignmentInBytes == >>>>>>> LogKlassAlignmentInBytes) { >>>>>>> + // For small heaps, save some space for compressed >>>>>>> class pointer >>>>>>> + // space with no base, only when >>>>>>> ObjAlignmentInBytes is 64 bits. >>>>>>> + uint64_t class_space = >>>>>>> align_size_up(CompressedClassSpaceSize, alignment); >>>>>>> + assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>>>>> + alignment), "difference must be aligned too"); >>>>>>> + uint64_t new_top = OopEncodingHeapMax-class_space; >>>>>>> + >>>>>>> + if (total_size <= new_top) { >>>>>>> + base = (new_top - heap_size); >>>>>>> + } else { >>>>>>> + base = (OopEncodingHeapMax - heap_size); >>>>>>> + } >>>>>>> >>>>>>> I don't understand why you have this restriction: >>>>>>> LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes >>>>>>> >>>>>> >>>>>> Because if you use a bigger ObjAlignmentInBytes, you probably >>>>>> have a bigger heap and this won't work anyway and I didn't want >>>>>> to support and test it. >>>>> >>>>> OK. Could you change the check to compare >>>>> LogMinObjAlignmentInBytes to 3, or ObjAlignmentInBytes to 8, or >>>>> OopEncodingHeapMax to 32GB? That would be much more clear too me. >>>>> >>>>>> I am rerunning some tests on the fixes. I'll send out another >>>>>> webrev shortly. >>>>>> >>>>>> Thanks so much for breaking my code! Srsly. >>>>> >>>>> OK. I'll wait for the update. >>>>> >>>>> thanks, >>>>> StefanK >>>>>> >>>>>> Coleen >>>>>> >>>>>>> thanks, >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 >>>>>>>> solaris/x64 and windows/x64 (in progress). Also running >>>>>>>> refworkload. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>>> >>>>> >>>> >>> >> > From john.coomes at oracle.com Fri Oct 25 13:10:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Oct 2013 20:10:20 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20131025201127.D51E56276B@hg.openjdk.java.net> Changeset: 1d1ea10fe09f Author: mgerdin Date: 2013-10-15 13:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d1ea10fe09f 8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it. Summary: Chunk up the last piece of committed memory in a VSN when getting a new one. Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 91a88c8450f4 Author: mgerdin Date: 2013-10-18 09:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91a88c8450f4 8026698: Incorrect error handling in Metaspace::allocate Reviewed-by: stefank, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: a1b05d4a6fd0 Author: stefank Date: 2013-10-21 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a1b05d4a6fd0 8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace Reviewed-by: mgerdin, brutisso + test/gc/TestSystemGC.java Changeset: 3dd24766da44 Author: stefank Date: 2013-10-21 01:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3dd24766da44 Merge Changeset: 2fab5b7e6140 Author: ehelin Date: 2013-10-21 14:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2fab5b7e6140 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Reviewed-by: coleenp, mgerdin, sspitsyn ! src/share/vm/prims/jvmtiImpl.cpp Changeset: c7f403b05168 Author: sjohanss Date: 2013-10-22 11:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c7f403b05168 8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values. Reviewed-by: stefank, ehelin ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp Changeset: 0823c8bac468 Author: jcoomes Date: 2013-10-22 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0823c8bac468 Merge Changeset: 1b422ef5288a Author: tschatzl Date: 2013-10-23 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b422ef5288a 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes. Reviewed-by: iveresov, simonis, tschatzl Contributed-by: Axel Siebenborn ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp Changeset: 0dcdec729cda Author: jcoomes Date: 2013-10-25 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0dcdec729cda Merge From john.r.rose at oracle.com Fri Oct 25 15:13:07 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 25 Oct 2013 15:13:07 -0700 Subject: 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D0453D1@DEWDFEMB12A.global.corp.sap> References: <52689C1A.8040305@oracle.com> <4295855A5C1DE049A61835A1887419CC0D044EEE@DEWDFEMB12A.global.corp.sap> <52692F31.2040803@oracle.com> <4295855A5C1DE049A61835A1887419CC0D0453D1@DEWDFEMB12A.global.corp.sap> Message-ID: <450DED4C-2344-486A-894F-D18AAB98E79E@oracle.com> On Oct 25, 2013, at 5:22 AM, "Lindenmaier, Goetz" wrote: > I think there would be enough space for extending the compressed class space to higher addresses, if you layout the spaces like this (assuming shift 3): These are good thought experiments. I'll contribute a few more. I took a quick look at current size scales for the JDK. There are about 30K classes and 230K methods in rt.jar (JDK 8). This means that the basic JDK uses (to half an order of magnitude) 0.3 million metadata nodes. (We never load it all at once, but let's use it as a proxy for complex application.) Meanwhile, the jar size is about 67Mb uncompressed, which expands about 1.5x to 3x when loaded. (Bytecodes don't expand, UTF8 strings contract about 2x due to interning, u2 indexes expand by 2x or 4x, and there are lots of extra headers and side tables.) Call it 100Mb in memory. That works out to 300 bytes per node; the methods probably dominate in size (as well as in number), followed by the constant pool part of each class. (A pointer to actual figures would help but I don't have one; I'm working from memory here of various adventures in footprint analysis and jar packing.) You can increase that size (of rt.jar) by 30x and still be able to address metadata with an unscaled 32-bit offset. That would be about 1M classes. You can increase the size almost arbitrarily by scaling the 32-bit offset. I've heard reports (for other kinds of scaled pointers) of scales all the way up to cache line sizes being sometimes workable. Say we allow up to 32x (5 bit positions). That goes to (order of magnitude) 1000x the metadata contained in rt.jar, which would be something like 30M classes. I've made the assumption so that all metadata pointers could be compressed. By special-casing class pointers (which is what we do today anyway), we can represent up to 2**32 classes by using another level of indirection. That's 100x the previous paragraph, surely more than anyone would ever need, right? :-) Compressing metadata pointers would allow metadata to get smaller, but would be somewhat difficult in our present code base. Another reason to concentrate on class pointers (and not general metadata pointers) is that they are the connection between the Java heap and the metadata heap. There are many ways to consider reducing header size. One possible tactic is to reduce the size of the class reference (oopDesc::_klass) to something even smaller than 32 bits. This would put a different inflection point on metadata costs, the number of classes at which an object header has to have some sort of expansion. But a mere 20 bits would be enough to address the middle scaling point mentioned above, of 1M classes. For a 64-bit uncompressed system, the same bits could be moved into every reference (and still leave 44 bits of dynamic range for heap addresses), allowing object headers to shrink to just a few bits (depending on what the mark word needs?that requirement can be tuned downward also). Finally, there is another way that we might push toward a scale of (say) 1M classes, and that is by introducing "species" (split classes) to differentiate objects nominally of the same class but with some internal distinction. Reified generics can be done this way, for example. So can "hidden classes" a la Self or JavaScript, or just some general kind of typestate. The effect of having split classes would be to increase the required dynamic range of the _klass field. This could also create pressure to use the extra level of indirection. (Coleen, we talked briefly about this last time we had lunch.) The costs of the extra level of indirection can be (I think) more or less continuously tuned by copying more or less of the "far class" into the "near class" (or "species") structure stored in the array indexed by the class/species number. In other words, if we are indexing classes, there's a big global array of them, and the array has a constant element size. A larger element size allows more information (such as the first N vtable entries) to be made available in one indirection, while a smaller element size allows for less duplication or fragmentation. An element size of several cache lines (esp. not an even-numbered "several") might be the sweet spot. (And so on. There's a different set of directions to go in when thinking about sharable images...) ? John From john.r.rose at oracle.com Fri Oct 25 16:17:01 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 25 Oct 2013 16:17:01 -0700 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <1828254.FSQ7MTpyjg@mgerdin03> References: <1828254.FSQ7MTpyjg@mgerdin03> Message-ID: <3DB19E0C-3CF8-423C-90AE-B16F50102781@oracle.com> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin wrote: > It appears to have > surfaced after we've reduced the unnecessary alignment "cushions" for > metaspace together with the fact that we are now always able to use the very > last bit of a VirtualSpace (in Metaspace). This sort of bug usually comes with a long line of siblings, each subsequent one 50% of the probability of the previous. So it's usually a mistake to use every last byte up to the end of a memory region, unless you are looking for trouble (electric fence, etc.). If it's gone away, I strongly suggest putting *back* a cache line or two worth of explicit padding at the end of every region that precedes unmapped memory. With a comment saying "don't try to optimize this". There are literally hundreds of better ways to buy back a byte or two than using the end of a memory region. I'm not discouraging you to fix those particular problems in the interpreter, but I am strongly disputing the wisdom of running all the way up to the edge of the page. ? John From john.r.rose at oracle.com Fri Oct 25 16:35:48 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 25 Oct 2013 16:35:48 -0700 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <3DB19E0C-3CF8-423C-90AE-B16F50102781@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <3DB19E0C-3CF8-423C-90AE-B16F50102781@oracle.com> Message-ID: On Oct 25, 2013, at 4:17 PM, John Rose wrote: > I strongly suggest putting *back* a cache line or two worth of explicit padding FTR, filed https://bugs.openjdk.java.net/browse/JDK-8027352 to track this. ? John From alejandro.murillo at oracle.com Fri Oct 25 16:49:18 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 25 Oct 2013 23:49:18 +0000 Subject: hg: hsx/hsx25/hotspot: 79 new changesets Message-ID: <20131025235244.8833D62772@hg.openjdk.java.net> Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 1a93f2c5945a Author: lana Date: 2013-10-17 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1a93f2c5945a Merge ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! src/share/vm/classfile/classFileParser.cpp Changeset: 4589b398ab03 Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4589b398ab03 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 4a1128861221 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a1128861221 Added tag jdk8-b113 for changeset 4589b398ab03 ! .hgtags Changeset: d6d8aeb2c2d4 Author: amurillo Date: 2013-10-19 08:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d6d8aeb2c2d4 8026928: new hotspot build - hs25-b56 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 384c92148c68 Author: amurillo Date: 2013-10-21 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/384c92148c68 8023496: [jprt] build and test solaris 64-bits only Reviewed-by: tbell, jcoomes ! make/jprt.properties Changeset: f9d4ed6c88dd Author: dholmes Date: 2013-10-21 20:51 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9d4ed6c88dd 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Reviewed-by: sla, sspitsyn ! test/TEST.groups Changeset: 8cd1abf3ecab Author: dholmes Date: 2013-10-21 21:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8cd1abf3ecab Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 2036c97e3af0 Author: dholmes Date: 2013-10-21 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2036c97e3af0 Merge Changeset: 7fe6ef09d242 Author: farvidsson Date: 2013-10-16 09:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7fe6ef09d242 8025638: jmap returns 0 instead of 1 when it fails. Summary: Re-factored some code handling return values and fails/errors during tool execution. Reviewed-by: sla, kevinw Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 042cf42c72bd Author: simonis Date: 2013-10-16 15:06 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/042cf42c72bd 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Reviewed-by: sla, kamg ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceTypes.xsl Changeset: d248425bcfe8 Author: hseigel Date: 2013-10-16 14:32 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d248425bcfe8 8024804: Crash when InterfaceMethodref resolves to Object.registerNatives Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods. Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8024804/RegisterNatives.java Changeset: 9e0ef3f02648 Author: hseigel Date: 2013-10-16 15:26 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9e0ef3f02648 Merge Changeset: 1bee3014cf2a Author: dsamersoff Date: 2013-10-17 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1bee3014cf2a 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Summary: Coredump store memsz elf field rounded up to page Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ffb471203842 Author: erikj Date: 2013-10-17 16:11 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ffb471203842 8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! make/windows/makefiles/trace.make Changeset: ad8e901ca2e1 Author: sla Date: 2013-10-17 12:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ad8e901ca2e1 Merge Changeset: d2db09f281ca Author: dsamersoff Date: 2013-10-17 16:45 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d2db09f281ca 8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime. Serviceability agent support was updated for this data Reviewed-by: coleenp, minqi, sla Contributed-by: eric.mccorkle at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b942ac65ac86 Author: dsamersoff Date: 2013-10-17 17:01 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b942ac65ac86 Merge Changeset: d0453d2fd045 Author: dsamersoff Date: 2013-10-18 10:37 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0453d2fd045 Merge Changeset: ee99e1a7c5fb Author: ccheung Date: 2013-10-18 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ee99e1a7c5fb Merge ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 996d1f2f056f Author: dsamersoff Date: 2013-10-19 21:29 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/996d1f2f056f 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 1327b7f85503 Author: ccheung Date: 2013-10-21 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1327b7f85503 Merge Changeset: 662c154d2749 Author: hseigel Date: 2013-10-22 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/662c154d2749 8026394: Eclipse fails with JDK8 build 111 Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object. With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE. Reviewed-by: acorn, dholmes Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8026394/InterfaceObjectTest.java Changeset: b8860472c377 Author: iklam Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b8860472c377 8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread Summary: Revert changes in JDK-8008962 Reviewed-by: coleenp, sspitsyn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 28be4c586b70 Author: iklam Date: 2013-10-22 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/28be4c586b70 Merge Changeset: a997d762fa20 Author: hseigel Date: 2013-10-22 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a997d762fa20 8026809: [TESTBUG] Create regression test for JDK-8026041 Summary: Created simple regression test for the bug Reviewed-by: hseigel, lfoltan, zgu Contributed-by: mikhailo.seledtsov at oracle.com + test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java Changeset: c183576a2dd1 Author: hseigel Date: 2013-10-22 22:14 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c183576a2dd1 Merge Changeset: b658cfe35857 Author: farvidsson Date: 2013-10-23 10:24 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b658cfe35857 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Summary: Fixes a bug with vmArgs when using JDKToolLauncher Reviewed-by: sla, dholmes ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: b3a4d4279fa3 Author: ccheung Date: 2013-10-24 17:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b3a4d4279fa3 Merge Changeset: 74e00b98d5dd Author: anoll Date: 2013-10-17 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/74e00b98d5dd 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase size for the template interpreter accordingly Reviewed-by: kvn, twisti ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: 1856ea98184a Author: adlertz Date: 2013-10-18 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1856ea98184a 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Summary: Enables private copies of inputs for recent spill copies as well Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/reg_split.cpp Changeset: e3b736cf4fa3 Author: adlertz Date: 2013-10-18 09:36 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e3b736cf4fa3 Merge Changeset: 252d541466ea Author: morris Date: 2013-10-18 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/252d541466ea 8008242: VerifyOops is broken on SPARC Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3213ba4d3dff Author: roland Date: 2013-10-19 12:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3213ba4d3dff 8024069: replace_in_map() should operate on parent maps Summary: type information gets lost because replace_in_map() doesn't update parent maps Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.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/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 19c5a042b0b3 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/19c5a042b0b3 8026414: [TESTBUG] Tests for Tiered/NonTiered levels Reviewed-by: twisti, iveresov + test/compiler/tiered/CompLevelsTest.java + test/compiler/tiered/NonTieredLevelsTest.java + test/compiler/tiered/TieredLevelsTest.java Changeset: 600c83f8e6a5 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/600c83f8e6a5 8023318: compiler/whitebox tests timeout with enabled TieredCompilation Reviewed-by: kvn, twisti ! test/compiler/whitebox/CompilerWhiteBoxTest.java Changeset: e842cc2d2dfb Author: iveresov Date: 2013-10-19 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e842cc2d2dfb Merge Changeset: 52575a17a36c Author: iignatyev Date: 2013-10-21 09:21 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/52575a17a36c 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Reviewed-by: twisti, iveresov ! test/compiler/print/PrintInlining.java Changeset: 4748b3308cda Author: iveresov Date: 2013-10-21 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4748b3308cda Merge Changeset: 5ccbab1c69f3 Author: roland Date: 2013-10-22 09:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ccbab1c69f3 8026251: New type profiling points: parameters to methods Summary: x86 interpreter and c1 type profiling for parameters on method entries Reviewed-by: kvn, twisti ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp + src/cpu/x86/vm/interp_masm_x86.cpp + src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: 435c7b4577cd Author: rbackman Date: 2013-10-21 15:31 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/435c7b4577cd 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Reviewed-by: iveresov, roland ! src/share/vm/opto/compile.cpp Changeset: 36e17466dd39 Author: rbackman Date: 2013-10-22 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/36e17466dd39 Merge Changeset: 8b4bbba322d3 Author: anoll Date: 2013-10-23 10:00 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b4bbba322d3 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper() Reviewed-by: roland, iveresov ! src/share/vm/compiler/compileBroker.cpp Changeset: b2ee5dc63353 Author: roland Date: 2013-10-23 12:40 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b2ee5dc63353 8024070: C2 needs some form of type speculation Summary: record unused type profile information with type system, propagate and use it. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.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/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp + test/compiler/types/TypeSpeculation.java Changeset: 4c9115774c8e Author: adlertz Date: 2013-10-23 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4c9115774c8e 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor Reviewed-by: roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 97d400662426 Author: adlertz Date: 2013-10-23 19:22 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/97d400662426 Merge Changeset: 9acbfe04b5c3 Author: iveresov Date: 2013-10-23 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9acbfe04b5c3 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator Reviewed-by: twisti, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 1c90f0072f0d Author: twisti Date: 2013-10-23 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1c90f0072f0d 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3a04e444da6d Author: iveresov Date: 2013-10-23 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a04e444da6d Merge Changeset: 59e8ad757e19 Author: rbackman Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/59e8ad757e19 8026844: Various Math functions needs intrinsification Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/AddExactICondTest.java + test/compiler/intrinsics/mathexact/AddExactIConstantTest.java + test/compiler/intrinsics/mathexact/AddExactILoadTest.java + test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java + test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java + test/compiler/intrinsics/mathexact/AddExactLConstantTest.java + test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/DecExactITest.java + test/compiler/intrinsics/mathexact/DecExactLTest.java + test/compiler/intrinsics/mathexact/IncExactITest.java + test/compiler/intrinsics/mathexact/IncExactLTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactICondTest.java + test/compiler/intrinsics/mathexact/MulExactIConstantTest.java + test/compiler/intrinsics/mathexact/MulExactILoadTest.java + test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java + test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java + test/compiler/intrinsics/mathexact/MulExactLConstantTest.java + test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactIConstantTest.java + test/compiler/intrinsics/mathexact/NegExactILoadTest.java + test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java + test/compiler/intrinsics/mathexact/SubExactICondTest.java + test/compiler/intrinsics/mathexact/SubExactIConstantTest.java + test/compiler/intrinsics/mathexact/SubExactILoadTest.java + test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java + test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java + test/compiler/intrinsics/mathexact/SubExactLConstantTest.java + test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java Changeset: 68f07c29521b Author: anoll Date: 2013-10-15 08:38 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/68f07c29521b 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Summary: Remove duplicate print Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: d95eca175eff Author: sspitsyn Date: 2013-10-23 20:15 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d95eca175eff 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose ! src/share/vm/prims/methodHandles.cpp Changeset: 0d1661d63d70 Author: vlivanov Date: 2013-10-23 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0d1661d63d70 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: f7d928a3181c Author: roland Date: 2013-10-24 19:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f7d928a3181c 8026978: JSR292: fatal error: Type profiling not implemented on this platform Summary: force TypeProfileLevel to 0 on non x86 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp Changeset: 395499125cb0 Author: iveresov Date: 2013-10-24 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/395499125cb0 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 6b32b911d723 Author: iveresov Date: 2013-10-24 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b32b911d723 Merge ! src/share/vm/runtime/vmStructs.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1d1ea10fe09f Author: mgerdin Date: 2013-10-15 13:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1d1ea10fe09f 8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it. Summary: Chunk up the last piece of committed memory in a VSN when getting a new one. Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 91a88c8450f4 Author: mgerdin Date: 2013-10-18 09:31 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/91a88c8450f4 8026698: Incorrect error handling in Metaspace::allocate Reviewed-by: stefank, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: a1b05d4a6fd0 Author: stefank Date: 2013-10-21 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a1b05d4a6fd0 8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace Reviewed-by: mgerdin, brutisso + test/gc/TestSystemGC.java Changeset: 3dd24766da44 Author: stefank Date: 2013-10-21 01:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3dd24766da44 Merge Changeset: 2fab5b7e6140 Author: ehelin Date: 2013-10-21 14:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2fab5b7e6140 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Reviewed-by: coleenp, mgerdin, sspitsyn ! src/share/vm/prims/jvmtiImpl.cpp Changeset: c7f403b05168 Author: sjohanss Date: 2013-10-22 11:50 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c7f403b05168 8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values. Reviewed-by: stefank, ehelin ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp Changeset: 0823c8bac468 Author: jcoomes Date: 2013-10-22 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0823c8bac468 Merge Changeset: 1b422ef5288a Author: tschatzl Date: 2013-10-23 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b422ef5288a 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes. Reviewed-by: iveresov, simonis, tschatzl Contributed-by: Axel Siebenborn ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp Changeset: 0dcdec729cda Author: jcoomes Date: 2013-10-25 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0dcdec729cda Merge Changeset: 82a9cdbf683e Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/82a9cdbf683e Merge ! src/share/vm/services/diagnosticCommand.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: bde83ddf920c Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bde83ddf920c Added tag hs25-b56 for changeset 82a9cdbf683e ! .hgtags From vitalyd at gmail.com Fri Oct 25 17:44:03 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 Oct 2013 20:44:03 -0400 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <141f0f43430.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> <526AB963.10305@oracle.com> <141f0f43430.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Message-ID: Mikael, If you're inclined, you can use xchg (on Intel at least) to do a 16 bit bswap equivalent - would save you the shift instruction and xchg of this form would be just 1 byte encoding (I.e. instruction size). Doubt performance will be noticeable though ... Sent from my phone On Oct 25, 2013 2:51 PM, "Mikael Gerdin" wrote: > Coleen, > > On 25 October 2013 20:33:07 Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> Mikael, >> >> This is really good work! Thank you for narrowing this down from the >> core file because we were going to have a lot of trouble reproducing this. >> > > Thanks! > > >> The code changes look good but why do you still need the bswapl and shrl? >> Doesn't load_unsigned_short load the value without sign extending also? >> I'm only guessing what bswapl does from the context though. >> > > Since the bytecode stores big endian values we still need to convert them > to native (little endian) byte order. > > So if we have the bytecode: > checkcast #6 0xc0 0x00 0x06 > > After the load we end up with > 0x00000600 > Bswap turns this to > 0x00060000 > The shift gets us > 0x00000006 > > (if someone could sanity-check this for me it would be great) > > /Mikael > > >> void TemplateTable::locals_index_**wide(Register reg) { >> - __ movl(reg, at_bcp(2)); >> + __ load_unsigned_short(reg, at_bcp(2)); >> __ bswapl(reg); >> __ shrl(reg, 16); >> __ negptr(reg); >> } >> >> Thanks, >> Coleen >> >> On 10/25/2013 12:46 PM, Mikael Gerdin wrote: >> > >> > >> > On 25 October 2013 18:25:47 Christian Thalinger < >> christian.thalinger at oracle.**com > wrote: >> >> Good catch. Is there a similar issue on SPARC? >> > >> > I looked through the other platforms, they all seem to do single-byte >> loads for the indices. >> > On SPARC I suppose it's because it can't do unaligned multibyte loads. >> > /Mikael >> > >> >> >> >> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin >> wrote: >> >> >> >> > Hi all, >> >> > Initially I'd like to hear people's opinions on this issue. It >> appears to have surfaced after we've reduced the unnecessary alignment >> "cushions" for metaspace together with the fact that we are now always able >> to use the very last bit of a VirtualSpace (in Metaspace). >> >> > The issue is extremely difficult to reproduce, because it relies on >> the exact order and size of all metaspace allocations for a run to trigger >> this problem. >> >> > Description of the problem: >> >> > We recently had some mysterious crashes in the GC testing, and I >> narrowed them down to the following scenario: >> >> > Imagine that we have a VirtualSpace (for Metaspace) >> >> > [ | bb] >> >> > ConstMethod >> >> > And that the very last object allocated in such a space is a >> ConstMethod, and that it has its embedded bytecodes filling up to the very >> end. >> >> > Consider the case when the second last bytecode (the one before >> "Xreturn") is one with an embedded 2-byte index (a constant pool or local >> variable index) for example: >> >> > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - (bcp+4) >> UNMAPPED MEMORY >> >> > The template interpreter here uses a 4-byte load on intel to read >> the index embedded in the checkcast: >> >> > mov 0x1(%esi),%ebx >> >> > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. >> >> > I looked through the code for places where we do similar loads of >> 2-byte indexes and found the same problem for iload_w: >> >> > 0xe73f7fbb: mov 0x2(%esi),%ebx >> >> > 0xe73f7fbe: bswap %ebx >> >> > 0xe73f7fc0: shr $0x10,%ebx >> >> > I looked through most places where we emit >> >> > __ movl >> >> > __ bswap >> >> > and changed the places I could find which were affected. >> >> > Suggested fix: >> >> > Replace movl with load_[un]signed_short in the places where we load >> 2-byte values from the byte code stream. >> >> > I've verified that load_unsigned_short (which boils down to movzwl, >> opcodes 0x0f 0xb7 only reads 2 bytes). >> >> > Buglink: https://bugs.openjdk.java.net/**browse/JDK-8027252 >> >> > Webrev: http://cr.openjdk.java.net/~**mgerdin/8027252/webrev.0/ >> >> > Testing: >> >> > vm.quick.testlist -Xint on linux-i586 and x86_64(running) >> >> > Thanks >> >> > /Mikael >> >> >> > >> > >> >> > > From jeremymanson at google.com Fri Oct 25 19:35:24 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 25 Oct 2013 19:35:24 -0700 Subject: Trivial bug in psScavenge.cpp? Message-ID: Hi folks, Following my habit of reporting trivial bugs (and perhaps my habit of being wrong about their being bugs). I've been playing around with the event-based JVM tracing API, since we had our own version of the same thing internally (amusingly, we called our timer TraceGCTime instead of GCTraceTime, but it did almost exactly the same thing). I noticed this in psScavenge.cpp: 469 GCTraceTime tm("StringTable", false, false, &_gc_timer); 470 // Unlink any dead interned Strings and process the remaining live ones. 471 PSScavengeRootsClosure root_closure(promotion_manager); 472 StringTable::unlink_or_oops_do(&_is_alive_closure, &root_closure); That's all well and good, but surely you want curly braces before line 469 and after line 472? Otherwise it credits a lot more time to string table processing than is appropriate... Jeremy From francis.andre.kampbell at orange.fr Sat Oct 26 13:19:58 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sat, 26 Oct 2013 22:19:58 +0200 Subject: -Xint: template or c++ interpreter? Message-ID: <526C23EE.6090803@orange.fr> Hi The -Xint option specifies to the JVM to run only in interpreted mode, but since compiling the JVM with CC_INTERP do not exclude the template Interpreter, I am wondering if there is an option to specify that only the template Interpreter or only the C++ Interpreter be used? Francis From bob.vandette at oracle.com Sat Oct 26 14:27:57 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Sat, 26 Oct 2013 17:27:57 -0400 Subject: -Xint: template or c++ interpreter? In-Reply-To: <526C23EE.6090803@orange.fr> References: <526C23EE.6090803@orange.fr> Message-ID: Compiling Hotspot with CC_INTERP does exclude the template interpreter. You either build a template Interpreter or C++ Interpreter. Bob. On Oct 26, 2013, at 4:19 PM, Francis ANDRE wrote: > Hi > > The -Xint option specifies to the JVM to run only in interpreted mode, but since compiling the JVM with CC_INTERP do not exclude the template Interpreter, I am wondering if there is an option to specify that only the template Interpreter or only the C++ Interpreter be used? > > Francis From francis.andre.kampbell at orange.fr Sun Oct 27 07:56:25 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sun, 27 Oct 2013 15:56:25 +0100 Subject: -Xint: template or c++ interpreter? In-Reply-To: References: <526C23EE.6090803@orange.fr> Message-ID: <526D2999.2040205@orange.fr> Bob I would like to distinguished at run time the kind of interpreter used. Would something like that be acceptable or is there another way to publish it? (may be the wording is bad, but that's an idea). const char* Abstract_VM_Version::vm_info_string() { switch (Arguments::mode()) { case Arguments::_int: #ifdef CC_INTERP return UseSharedSpaces ? "code base interpreted mode, sharing" : "code base interpreted mode"; #else return UseSharedSpaces ? "template interpreted mode, sharing" : "template interpreted mode"; #endif // CC_INTERP case Arguments::_mixed: return UseSharedSpaces ? "mixed mode, sharing" : "mixed mode"; case Arguments::_comp: return UseSharedSpaces ? "compiled mode, sharing" : "compiled mode"; }; Francis Le 26/10/2013 23:27, Bob Vandette a ?crit : > Compiling Hotspot with CC_INTERP does exclude the template interpreter. > You either build a template Interpreter or C++ Interpreter. > > Bob. > > On Oct 26, 2013, at 4:19 PM, Francis ANDRE wrote: > >> Hi >> >> The -Xint option specifies to the JVM to run only in interpreted mode, but since compiling the JVM with CC_INTERP do not exclude the template Interpreter, I am wondering if there is an option to specify that only the template Interpreter or only the C++ Interpreter be used? >> >> Francis > From volker.simonis at gmail.com Sun Oct 27 10:06:59 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 27 Oct 2013 18:06:59 +0100 Subject: -Xint: template or c++ interpreter? In-Reply-To: <526D2999.2040205@orange.fr> References: <526C23EE.6090803@orange.fr> <526D2999.2040205@orange.fr> Message-ID: Hi Francis, as Bob pointed out, choosing the C++ vs. the Template Interpreter is currently a compile time decision. And I think it won't be easy to change that, because you will probably get name clashes with the current source code. Regards, Volker PS: by the way, your example is still compile time. On Sun, Oct 27, 2013 at 3:56 PM, Francis ANDRE wrote: > Bob > > I would like to distinguished at run time the kind of interpreter used. > Would something like that be acceptable or is there another way to publish > it? (may be the wording is bad, but that's an idea). > > const char* Abstract_VM_Version::vm_info_string() { > switch (Arguments::mode()) { > case Arguments::_int: > #ifdef CC_INTERP > return UseSharedSpaces ? "code base interpreted mode, sharing" : "code > base interpreted mode"; > #else > return UseSharedSpaces ? "template interpreted mode, sharing" : > "template interpreted mode"; > #endif // CC_INTERP > case Arguments::_mixed: > return UseSharedSpaces ? "mixed mode, sharing" : "mixed mode"; > case Arguments::_comp: > return UseSharedSpaces ? "compiled mode, sharing" : "compiled > mode"; > }; > > Francis > > Le 26/10/2013 23:27, Bob Vandette a ?crit : > >> Compiling Hotspot with CC_INTERP does exclude the template interpreter. >> You either build a template Interpreter or C++ Interpreter. >> >> Bob. >> >> On Oct 26, 2013, at 4:19 PM, Francis ANDRE >> wrote: >> >>> Hi >>> >>> The -Xint option specifies to the JVM to run only in interpreted mode, >>> but since compiling the JVM with CC_INTERP do not exclude the template >>> Interpreter, I am wondering if there is an option to specify that only the >>> template Interpreter or only the C++ Interpreter be used? >>> >>> Francis >> >> > From francis.andre.kampbell at orange.fr Sun Oct 27 11:41:17 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sun, 27 Oct 2013 19:41:17 +0100 Subject: -Xint: template or c++ interpreter? In-Reply-To: References: <526C23EE.6090803@orange.fr> <526D2999.2040205@orange.fr> Message-ID: <526D5E4D.2030603@orange.fr> Hi Volker Le 27/10/2013 18:06, Volker Simonis a ?crit : > Hi Francis, > > as Bob pointed out, choosing the C++ vs. the Template Interpreter is > currently a compile time decision. And I think > it won't be easy to change that, because you will probably get name > clashes with the current source code. I have no problem with the decision of choosing the C++ vs the template interpreter at compile time. My initial question was related to the fact that the hotspot code is relatively complex to understand at large and I wanted to be sure of running either the cpp interpreter either the template interpreter with may be an additional internal parameter. So the define CC_INTERP makes the choice and that's ok. > > Regards, > Volker > > PS: by the way, your example is still compile time. Yes, it is compile time but that information is produced running java -version and would be useful as a tracker of which interpreter is used. I want to identify the interpreter used in the jdk jtreg tests to avoid uncertainty. Francis > > On Sun, Oct 27, 2013 at 3:56 PM, Francis ANDRE > wrote: >> Bob >> >> I would like to distinguished at run time the kind of interpreter used. >> Would something like that be acceptable or is there another way to publish >> it? (may be the wording is bad, but that's an idea). >> >> const char* Abstract_VM_Version::vm_info_string() { >> switch (Arguments::mode()) { >> case Arguments::_int: >> #ifdef CC_INTERP >> return UseSharedSpaces ? "code base interpreted mode, sharing" : "code >> base interpreted mode"; >> #else >> return UseSharedSpaces ? "template interpreted mode, sharing" : >> "template interpreted mode"; >> #endif // CC_INTERP >> case Arguments::_mixed: >> return UseSharedSpaces ? "mixed mode, sharing" : "mixed mode"; >> case Arguments::_comp: >> return UseSharedSpaces ? "compiled mode, sharing" : "compiled >> mode"; >> }; >> >> Francis >> >> Le 26/10/2013 23:27, Bob Vandette a ?crit : >> >>> Compiling Hotspot with CC_INTERP does exclude the template interpreter. >>> You either build a template Interpreter or C++ Interpreter. >>> >>> Bob. >>> >>> On Oct 26, 2013, at 4:19 PM, Francis ANDRE >>> wrote: >>> >>>> Hi >>>> >>>> The -Xint option specifies to the JVM to run only in interpreted mode, >>>> but since compiling the JVM with CC_INTERP do not exclude the template >>>> Interpreter, I am wondering if there is an option to specify that only the >>>> template Interpreter or only the C++ Interpreter be used? >>>> >>>> Francis >>> From bengt.rutisson at oracle.com Mon Oct 28 01:10:30 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 28 Oct 2013 09:10:30 +0100 Subject: Trivial bug in psScavenge.cpp? In-Reply-To: References: Message-ID: <526E1BF6.6070403@oracle.com> Hi Jeremy, On 2013-10-26 04:35, Jeremy Manson wrote: > Hi folks, > > Following my habit of reporting trivial bugs (and perhaps my habit of being > wrong about their being bugs). I've been playing around with the > event-based JVM tracing API, since we had our own version of the same thing > internally (amusingly, we called our timer TraceGCTime instead of > GCTraceTime, but it did almost exactly the same thing). I noticed this in > psScavenge.cpp: > > 469 GCTraceTime tm("StringTable", false, false, &_gc_timer); > 470 // Unlink any dead interned Strings and process the remaining > live ones. > 471 PSScavengeRootsClosure root_closure(promotion_manager); > 472 StringTable::unlink_or_oops_do(&_is_alive_closure, > &root_closure); > > That's all well and good, but surely you want curly braces before line 469 > and after line 472? Otherwise it credits a lot more time to string table > processing than is appropriate... Nice catch! You are absolutely right. This section used to be inside an if statement, but that was removed and suddenly the timing got the wrong scope. Would you like to file a bug and provide a patch, or would you like me to help out with any of it? Thanks, Bengt > > Jeremy From thomas.schatzl at oracle.com Mon Oct 28 01:37:53 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Oct 2013 09:37:53 +0100 Subject: Trivial bug in psScavenge.cpp? In-Reply-To: <526E1BF6.6070403@oracle.com> References: <526E1BF6.6070403@oracle.com> Message-ID: <1382949473.2687.3.camel@cirrus> Hi, On Mon, 2013-10-28 at 09:10 +0100, Bengt Rutisson wrote: > Hi Jeremy, > > On 2013-10-26 04:35, Jeremy Manson wrote: > > Hi folks, > > > > Following my habit of reporting trivial bugs (and perhaps my habit of being > > wrong about their being bugs). I've been playing around with the > > event-based JVM tracing API, since we had our own version of the same thing > > internally (amusingly, we called our timer TraceGCTime instead of > > GCTraceTime, but it did almost exactly the same thing). I noticed this in > > psScavenge.cpp: > > > > 469 GCTraceTime tm("StringTable", false, false, &_gc_timer); > > 470 // Unlink any dead interned Strings and process the remaining > > live ones. > > 471 PSScavengeRootsClosure root_closure(promotion_manager); > > 472 StringTable::unlink_or_oops_do(&_is_alive_closure, > > &root_closure); > > > > That's all well and good, but surely you want curly braces before line 469 > > and after line 472? Otherwise it credits a lot more time to string table > > processing than is appropriate... > > Nice catch! > > You are absolutely right. This section used to be inside an if > statement, but that was removed and suddenly the timing got the wrong scope. > > Would you like to file a bug and provide a patch, or would you like me > to help out with any of it? I filed the CR already at https://bugs.openjdk.java.net/browse/JDK-8027364 - still, maybe you want to provide a webrev/patch :) Thomas From staffan.larsen at oracle.com Mon Oct 28 04:57:34 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Oct 2013 12:57:34 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <5269272F.6090907@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> <52663633.2080206@oracle.com> <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> <5269272F.6090907@oracle.com> Message-ID: <8BB9C412-6A40-48D7-8EFC-4A8AFC3DD581@oracle.com> This looks a lot better. Just few more comments: ToolConfig.java L72 - "getToolOptins" -> "getToolOptions" L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? Thanks, /Staffan On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: > Hi, > > I've done following big changes after the Staffan's review: > - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig > - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM > - tools will be launched without -vmoptions > > plus made fixes for all minor comments. > > If it's a good idea to push testlibrary changes separately I can make a separate patch for them. > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja > > > > On 10/23/2013 12:55 PM, Staffan Larsen wrote: >> test/lib/testlibrary/jdk/testlibrary/Asserts.java >> Same code as already exists in the hotspot testlibrary. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >> L33: stating -> starting >> L66: staring -> starting >> >> >> test/lib/testlibrary/jdk/testlibrary/TestThread.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/Utils.java >> No comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/XRun.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/sun/tools/jstatd/JstatGcutilParser.java >> The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. >> >> I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? >> >> L67: getType() should be private. >> >> >> test/sun/tools/jstatd/JstatdHelper.java: >> L54: Does verifyJpsOutput() work correctly with output of the form: >> >> 1234 -- main class information unavailable >> 1235 -- process information unavailable >> >> Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >> >> L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? >> >> >> test/sun/tools/jstatd/TestJstatdDefaults.java >> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >> test/sun/tools/jstatd/TestJstatdPort.java >> test/sun/tools/jstatd/TestJstatdPortAndServer.java >> test/sun/tools/jstatd/TestJstatdServer.java >> No comments. >> >> >> test/sun/tools/jstatd/TestJstatdUsage.java >> Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >> >> >> test/sun/tools/jstatd/ToolConfig.java >> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? >> >> You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? >> >> >> General comments: >> >> Can't we do: >> * @library /lib/testlibrary >> instead of >> * @library ../../../lib/testlibrary >> ? >> >> It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. >> >> While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. >> >> >> Thanks, >> /Staffan > From mikael.gerdin at oracle.com Mon Oct 28 06:46:48 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 28 Oct 2013 14:46:48 +0100 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: References: <1828254.FSQ7MTpyjg@mgerdin03> <141f0f43430.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Message-ID: <41912211.PKR1cNoDst@mgerdin03> Vitaly, On Friday 25 October 2013 20.44.03 Vitaly Davidovich wrote: > Mikael, > > If you're inclined, you can use xchg (on Intel at least) to do a 16 bit > bswap equivalent - would save you the shift instruction and xchg of this > form would be just 1 byte encoding (I.e. instruction size). Doubt > performance will be noticeable though ... Did you mean something like: xchg %bl, %bh The assembler in HotSpot currently does not implement that particular opcode, and since not all X86 registers are low/high byte addressable I'm not sure that the extra complexity is worth it. /Mikael > > Sent from my phone > > On Oct 25, 2013 2:51 PM, "Mikael Gerdin" wrote: > > Coleen, > > > > On 25 October 2013 20:33:07 Coleen Phillimore < > > > > coleen.phillimore at oracle.com> wrote: > >> Mikael, > >> > >> This is really good work! Thank you for narrowing this down from the > >> core file because we were going to have a lot of trouble reproducing > >> this. > > > > Thanks! > > > >> The code changes look good but why do you still need the bswapl and shrl? > >> > >> Doesn't load_unsigned_short load the value without sign extending also? > >> > >> I'm only guessing what bswapl does from the context though. > > > > Since the bytecode stores big endian values we still need to convert them > > to native (little endian) byte order. > > > > So if we have the bytecode: > > checkcast #6 0xc0 0x00 0x06 > > > > After the load we end up with > > 0x00000600 > > Bswap turns this to > > 0x00060000 > > The shift gets us > > 0x00000006 > > > > (if someone could sanity-check this for me it would be great) > > > > /Mikael > > > >> void TemplateTable::locals_index_**wide(Register reg) { > >> > >> - __ movl(reg, at_bcp(2)); > >> + __ load_unsigned_short(reg, at_bcp(2)); > >> > >> __ bswapl(reg); > >> __ shrl(reg, 16); > >> __ negptr(reg); > >> > >> } > >> > >> Thanks, > >> Coleen > >> > >> On 10/25/2013 12:46 PM, Mikael Gerdin wrote: > >> > On 25 October 2013 18:25:47 Christian Thalinger < > >> > >> christian.thalinger at oracle.**com > wrote: > >> >> Good catch. Is there a similar issue on SPARC? > >> > > >> > I looked through the other platforms, they all seem to do single-byte > >> > >> loads for the indices. > >> > >> > On SPARC I suppose it's because it can't do unaligned multibyte loads. > >> > /Mikael > >> > > >> >> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin > >> > >> wrote: > >> >> > Hi all, > >> >> > Initially I'd like to hear people's opinions on this issue. It > >> > >> appears to have surfaced after we've reduced the unnecessary alignment > >> "cushions" for metaspace together with the fact that we are now always > >> able > >> to use the very last bit of a VirtualSpace (in Metaspace). > >> > >> >> > The issue is extremely difficult to reproduce, because it relies on > >> > >> the exact order and size of all metaspace allocations for a run to > >> trigger > >> this problem. > >> > >> >> > Description of the problem: > >> >> > We recently had some mysterious crashes in the GC testing, and I > >> > >> narrowed them down to the following scenario: > >> >> > Imagine that we have a VirtualSpace (for Metaspace) > >> >> > [ | bb] > >> >> > > >> >> > ConstMethod > >> >> > > >> >> > And that the very last object allocated in such a space is a > >> > >> ConstMethod, and that it has its embedded bytecodes filling up to the > >> very > >> end. > >> > >> >> > Consider the case when the second last bytecode (the one before > >> > >> "Xreturn") is one with an embedded 2-byte index (a constant pool or local > >> > >> variable index) for example: > >> >> > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - (bcp+4) > >> > >> UNMAPPED MEMORY > >> > >> >> > The template interpreter here uses a 4-byte load on intel to read > >> > >> the index embedded in the checkcast: > >> >> > mov 0x1(%esi),%ebx > >> >> > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > >> >> > I looked through the code for places where we do similar loads of > >> > >> 2-byte indexes and found the same problem for iload_w: > >> >> > 0xe73f7fbb: mov 0x2(%esi),%ebx > >> >> > 0xe73f7fbe: bswap %ebx > >> >> > 0xe73f7fc0: shr $0x10,%ebx > >> >> > > >> >> > I looked through most places where we emit > >> >> > __ movl > >> >> > __ bswap > >> >> > and changed the places I could find which were affected. > >> >> > Suggested fix: > >> >> > Replace movl with load_[un]signed_short in the places where we load > >> > >> 2-byte values from the byte code stream. > >> > >> >> > I've verified that load_unsigned_short (which boils down to movzwl, > >> > >> opcodes 0x0f 0xb7 only reads 2 bytes). > >> > >> >> > Buglink: > >> >> > https://bugs.openjdk.java.net/**browse/JDK-8027252 >> >> > njdk.java.net/browse/JDK-8027252> Webrev: > >> >> > http://cr.openjdk.java.net/~**mgerdin/8027252/webrev.0/ >> >> > penjdk.java.net/~mgerdin/8027252/webrev.0/> Testing: > >> >> > vm.quick.testlist -Xint on linux-i586 and x86_64(running) > >> >> > Thanks > >> >> > /Mikael From mikael.gerdin at oracle.com Mon Oct 28 06:58:17 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 28 Oct 2013 14:58:17 +0100 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <3DB19E0C-3CF8-423C-90AE-B16F50102781@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <3DB19E0C-3CF8-423C-90AE-B16F50102781@oracle.com> Message-ID: <1890814.hsYALuccYW@mgerdin03> John, On Friday 25 October 2013 16.17.01 John Rose wrote: > On Oct 25, 2013, at 8:55 AM, Mikael Gerdin wrote: > > It appears to have > > surfaced after we've reduced the unnecessary alignment "cushions" for > > metaspace together with the fact that we are now always able to use the > > very last bit of a VirtualSpace (in Metaspace). > > This sort of bug usually comes with a long line of siblings, each subsequent > one 50% of the probability of the previous. > > So it's usually a mistake to use every last byte up to the end of a memory > region, unless you are looking for trouble (electric fence, etc.). > > If it's gone away, I strongly suggest putting *back* a cache line or two > worth of explicit padding at the end of every region that precedes unmapped > memory. With a comment saying "don't try to optimize this". No explicit padding has been removed. The allocation size alignment on 64-bit has been reduced from 16-byte to 8- byte, but this crash as appeared on 32-bit. A variable sized unreliable amount of padding has been removed because large metaspace allocations now align up to the smallest chunk size. This crash could have happened before as well, but it's highly dependent on the order of allocations. > > There are literally hundreds of better ways to buy back a byte or two than > using the end of a memory region. > > I'm not discouraging you to fix those particular problems in the > interpreter, but I am strongly disputing the wisdom of running all the way > up to the edge of the page. Ok, I'll go ahead with this change then. /Mikael > > ? John From bob.vandette at oracle.com Mon Oct 28 07:18:14 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 28 Oct 2013 10:18:14 -0400 Subject: -Xint: template or c++ interpreter? In-Reply-To: <526D5E4D.2030603@orange.fr> References: <526C23EE.6090803@orange.fr> <526D2999.2040205@orange.fr> <526D5E4D.2030603@orange.fr> Message-ID: <92AF990A-4FFE-444B-A8DA-00795F2BC424@oracle.com> I don't think we'd want to change the version string to include this type of implementation specific detail. If this is just for testing, how about looking for symbols specific to the interpreter implementation in the JVM? nm -C libjvm.so | grep TemplateTable::initialize or nm -C libjvm.so | grep CppInterpreter::initialize Bob. On Oct 27, 2013, at 2:41 PM, Francis ANDRE wrote: > Hi Volker > > Le 27/10/2013 18:06, Volker Simonis a ?crit : >> Hi Francis, >> >> as Bob pointed out, choosing the C++ vs. the Template Interpreter is >> currently a compile time decision. And I think >> it won't be easy to change that, because you will probably get name >> clashes with the current source code. > I have no problem with the decision of choosing the C++ vs the template interpreter at compile time. My initial question was related to the fact that the hotspot code is relatively complex to understand at large and I wanted to be sure of running either the cpp interpreter either the template interpreter with may be an additional internal parameter. So the define CC_INTERP makes the choice and that's ok. >> >> Regards, >> Volker >> >> PS: by the way, your example is still compile time. > Yes, it is compile time but that information is produced running java -version and would be useful as a tracker of which interpreter is used. I want to identify the interpreter used in the jdk jtreg tests to avoid uncertainty. > > Francis >> >> On Sun, Oct 27, 2013 at 3:56 PM, Francis ANDRE >> wrote: >>> Bob >>> >>> I would like to distinguished at run time the kind of interpreter used. >>> Would something like that be acceptable or is there another way to publish >>> it? (may be the wording is bad, but that's an idea). >>> >>> const char* Abstract_VM_Version::vm_info_string() { >>> switch (Arguments::mode()) { >>> case Arguments::_int: >>> #ifdef CC_INTERP >>> return UseSharedSpaces ? "code base interpreted mode, sharing" : "code >>> base interpreted mode"; >>> #else >>> return UseSharedSpaces ? "template interpreted mode, sharing" : >>> "template interpreted mode"; >>> #endif // CC_INTERP >>> case Arguments::_mixed: >>> return UseSharedSpaces ? "mixed mode, sharing" : "mixed mode"; >>> case Arguments::_comp: >>> return UseSharedSpaces ? "compiled mode, sharing" : "compiled >>> mode"; >>> }; >>> >>> Francis >>> >>> Le 26/10/2013 23:27, Bob Vandette a ?crit : >>> >>>> Compiling Hotspot with CC_INTERP does exclude the template interpreter. >>>> You either build a template Interpreter or C++ Interpreter. >>>> >>>> Bob. >>>> >>>> On Oct 26, 2013, at 4:19 PM, Francis ANDRE >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> The -Xint option specifies to the JVM to run only in interpreted mode, >>>>> but since compiling the JVM with CC_INTERP do not exclude the template >>>>> Interpreter, I am wondering if there is an option to specify that only the >>>>> template Interpreter or only the C++ Interpreter be used? >>>>> >>>>> Francis >>>> > From yekaterina.kantserova at oracle.com Mon Oct 28 09:12:25 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 28 Oct 2013 09:12:25 -0700 (PDT) Subject: Sv: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd Message-ID: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> Hi, http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: public class TestJstatdDefaults { public static void main(String[] args) throws Throwable { JstatdTest test = new JstatdTest(); test.doTest(); } } Hope it looks better now. Thanks, Katja ----- Ursprungligt meddelande ----- Fr?n: staffan.larsen at oracle.com Till: yekaterina.kantserova at oracle.com Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com, christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd This looks a lot better. Just few more comments: ToolConfig.java ? L72 - "getToolOptins" -> "getToolOptions" ? L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. ? Why are some tool-specific options added in?getToolOptins() and some in the?getJpsCmd()/getJstatdCmd()/... methods? Maybe changing?getToolOptins() to only return the host part of the options and moving the rest of the setup to?getJpsCmd()/getJstatdCmd()/...? Thanks, /Staffan On 24 okt 2013, at 15:57, Yekaterina Kantserova < yekaterina.kantserova at oracle.com > wrote: Hi, I've done following big changes after the Staffan's review: - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary ( http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot ) for re-using in ToolConfig - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM - tools will be launched without -vmoptions plus made fixes for all minor comments . If it's a good idea to push testlibrary changes separately I can make a separate patch for them. Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 Thanks, Katja On 10/23/2013 12:55 PM, Staffan Larsen wrote: test/lib/testlibrary/jdk/testlibrary/Asserts.java ? Same code as already exists in the hotspot testlibrary. ? No further comments. test/lib/testlibrary/jdk/testlibrary/ProcessThread.java ? L33: stating -> starting ? L66: staring -> starting test/lib/testlibrary/jdk/testlibrary/TestThread.java ? This code comes from an internal test library. ? No further comments. test/lib/testlibrary/jdk/testlibrary/Utils.java ? No comments. test/lib/testlibrary/jdk/testlibrary/XRun.java ? This code comes from an internal test library. ? No further comments. test/sun/tools/jstatd/JstatGcutilParser.java ? The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. ?? ? I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? ? L67:?getType() should be private. test/sun/tools/jstatd/JstatdHelper.java: ? L54: Does?verifyJpsOutput() work correctly with output of the form: 1234 --?main class information unavailable 1235?-- process information unavailable ? Also: same comment here as for?JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. ? L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? test/sun/tools/jstatd/TestJstatdDefaults.java test/sun/tools/jstatd/TestJstatdExternalRegistry.java test/sun/tools/jstatd/TestJstatdPort.java test/sun/tools/jstatd/TestJstatdPortAndServer.java test/sun/tools/jstatd/TestJstatdServer.java ? No comments. test/sun/tools/jstatd/TestJstatdUsage.java ? Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. test/sun/tools/jstatd/ToolConfig.java ? ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to?JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? ? You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional?? General comments: Can't we do: ? * @library /lib/testlibrary instead of ? * @library ../../../lib/testlibrary ? It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. Thanks, /Staffan From vitalyd at gmail.com Mon Oct 28 09:43:39 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 28 Oct 2013 12:43:39 -0400 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <41912211.PKR1cNoDst@mgerdin03> References: <1828254.FSQ7MTpyjg@mgerdin03> <141f0f43430.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> <41912211.PKR1cNoDst@mgerdin03> Message-ID: Right, that's the one. If it's unsupported, agree, not worth it. Thanks Sent from my phone On Oct 28, 2013 9:47 AM, "Mikael Gerdin" wrote: > Vitaly, > > On Friday 25 October 2013 20.44.03 Vitaly Davidovich wrote: > > Mikael, > > > > If you're inclined, you can use xchg (on Intel at least) to do a 16 bit > > bswap equivalent - would save you the shift instruction and xchg of this > > form would be just 1 byte encoding (I.e. instruction size). Doubt > > performance will be noticeable though ... > > Did you mean something like: > xchg %bl, %bh > > The assembler in HotSpot currently does not implement that particular > opcode, > and since not all X86 registers are low/high byte addressable I'm not sure > that the extra complexity is worth it. > > /Mikael > > > > > Sent from my phone > > > > On Oct 25, 2013 2:51 PM, "Mikael Gerdin" > wrote: > > > Coleen, > > > > > > On 25 October 2013 20:33:07 Coleen Phillimore < > > > > > > coleen.phillimore at oracle.com> wrote: > > >> Mikael, > > >> > > >> This is really good work! Thank you for narrowing this down from the > > >> core file because we were going to have a lot of trouble reproducing > > >> this. > > > > > > Thanks! > > > > > >> The code changes look good but why do you still need the bswapl and > shrl? > > >> > > >> Doesn't load_unsigned_short load the value without sign extending > also? > > >> > > >> I'm only guessing what bswapl does from the context though. > > > > > > Since the bytecode stores big endian values we still need to convert > them > > > to native (little endian) byte order. > > > > > > So if we have the bytecode: > > > checkcast #6 0xc0 0x00 0x06 > > > > > > After the load we end up with > > > 0x00000600 > > > Bswap turns this to > > > 0x00060000 > > > The shift gets us > > > 0x00000006 > > > > > > (if someone could sanity-check this for me it would be great) > > > > > > /Mikael > > > > > >> void TemplateTable::locals_index_**wide(Register reg) { > > >> > > >> - __ movl(reg, at_bcp(2)); > > >> + __ load_unsigned_short(reg, at_bcp(2)); > > >> > > >> __ bswapl(reg); > > >> __ shrl(reg, 16); > > >> __ negptr(reg); > > >> > > >> } > > >> > > >> Thanks, > > >> Coleen > > >> > > >> On 10/25/2013 12:46 PM, Mikael Gerdin wrote: > > >> > On 25 October 2013 18:25:47 Christian Thalinger < > > >> > > >> christian.thalinger at oracle.**com > > wrote: > > >> >> Good catch. Is there a similar issue on SPARC? > > >> > > > >> > I looked through the other platforms, they all seem to do > single-byte > > >> > > >> loads for the indices. > > >> > > >> > On SPARC I suppose it's because it can't do unaligned multibyte > loads. > > >> > /Mikael > > >> > > > >> >> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin < > mikael.gerdin at oracle.com> > > >> > > >> wrote: > > >> >> > Hi all, > > >> >> > Initially I'd like to hear people's opinions on this issue. It > > >> > > >> appears to have surfaced after we've reduced the unnecessary alignment > > >> "cushions" for metaspace together with the fact that we are now always > > >> able > > >> to use the very last bit of a VirtualSpace (in Metaspace). > > >> > > >> >> > The issue is extremely difficult to reproduce, because it relies > on > > >> > > >> the exact order and size of all metaspace allocations for a run to > > >> trigger > > >> this problem. > > >> > > >> >> > Description of the problem: > > >> >> > We recently had some mysterious crashes in the GC testing, and I > > >> > > >> narrowed them down to the following scenario: > > >> >> > Imagine that we have a VirtualSpace (for Metaspace) > > >> >> > [ | bb] > > >> >> > > > >> >> > ConstMethod > > >> >> > > > >> >> > And that the very last object allocated in such a space is a > > >> > > >> ConstMethod, and that it has its embedded bytecodes filling up to the > > >> very > > >> end. > > >> > > >> >> > Consider the case when the second last bytecode (the one before > > >> > > >> "Xreturn") is one with an embedded 2-byte index (a constant pool or > local > > >> > > >> variable index) for example: > > >> >> > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - > (bcp+4) > > >> > > >> UNMAPPED MEMORY > > >> > > >> >> > The template interpreter here uses a 4-byte load on intel to read > > >> > > >> the index embedded in the checkcast: > > >> >> > mov 0x1(%esi),%ebx > > >> >> > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > > >> >> > I looked through the code for places where we do similar loads of > > >> > > >> 2-byte indexes and found the same problem for iload_w: > > >> >> > 0xe73f7fbb: mov 0x2(%esi),%ebx > > >> >> > 0xe73f7fbe: bswap %ebx > > >> >> > 0xe73f7fc0: shr $0x10,%ebx > > >> >> > > > >> >> > I looked through most places where we emit > > >> >> > __ movl > > >> >> > __ bswap > > >> >> > and changed the places I could find which were affected. > > >> >> > Suggested fix: > > >> >> > Replace movl with load_[un]signed_short in the places where we > load > > >> > > >> 2-byte values from the byte code stream. > > >> > > >> >> > I've verified that load_unsigned_short (which boils down to > movzwl, > > >> > > >> opcodes 0x0f 0xb7 only reads 2 bytes). > > >> > > >> >> > Buglink: > > >> >> > https://bugs.openjdk.java.net/**browse/JDK-8027252< > https://bugs.ope > > >> >> > njdk.java.net/browse/JDK-8027252> Webrev: > > >> >> > http://cr.openjdk.java.net/~**mgerdin/8027252/webrev.0/< > http://cr.o > > >> >> > penjdk.java.net/~mgerdin/8027252/webrev.0/> Testing: > > >> >> > vm.quick.testlist -Xint on linux-i586 and x86_64(running) > > >> >> > Thanks > > >> >> > /Mikael > > From jeremymanson at google.com Mon Oct 28 10:15:54 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 28 Oct 2013 10:15:54 -0700 Subject: Trivial bug in psScavenge.cpp? In-Reply-To: <1382949473.2687.3.camel@cirrus> References: <526E1BF6.6070403@oracle.com> <1382949473.2687.3.camel@cirrus> Message-ID: It's pretty trivial, so unless my being involved will help anything, you guys can feel free to take care of it without me. Jeremy On Mon, Oct 28, 2013 at 1:37 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2013-10-28 at 09:10 +0100, Bengt Rutisson wrote: > > Hi Jeremy, > > > > On 2013-10-26 04:35, Jeremy Manson wrote: > > > Hi folks, > > > > > > Following my habit of reporting trivial bugs (and perhaps my habit of > being > > > wrong about their being bugs). I've been playing around with the > > > event-based JVM tracing API, since we had our own version of the same > thing > > > internally (amusingly, we called our timer TraceGCTime instead of > > > GCTraceTime, but it did almost exactly the same thing). I noticed > this in > > > psScavenge.cpp: > > > > > > 469 GCTraceTime tm("StringTable", false, false, &_gc_timer); > > > 470 // Unlink any dead interned Strings and process the > remaining > > > live ones. > > > 471 PSScavengeRootsClosure root_closure(promotion_manager); > > > 472 StringTable::unlink_or_oops_do(&_is_alive_closure, > > > &root_closure); > > > > > > That's all well and good, but surely you want curly braces before line > 469 > > > and after line 472? Otherwise it credits a lot more time to string > table > > > processing than is appropriate... > > > > Nice catch! > > > > You are absolutely right. This section used to be inside an if > > statement, but that was removed and suddenly the timing got the wrong > scope. > > > > Would you like to file a bug and provide a patch, or would you like me > > to help out with any of it? > > I filed the CR already at > https://bugs.openjdk.java.net/browse/JDK-8027364 - still, maybe you want > to provide a webrev/patch :) > > Thomas > > > > From staffan.larsen at oracle.com Mon Oct 28 11:02:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Oct 2013 19:02:50 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> Message-ID: <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). nit: JstatdTest.cleanUpThread() shouldn't be static. Thanks, /Staffan On 28 okt 2013, at 17:12, Yekaterina Kantserova wrote: > Hi, > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ > > Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: > > public class TestJstatdDefaults { > > public static void main(String[] args) throws Throwable { > JstatdTest test = new JstatdTest(); > test.doTest(); > } > > } > > Hope it looks better now. > > Thanks, > Katja > > ----- Ursprungligt meddelande ----- > Fr?n: staffan.larsen at oracle.com > Till: yekaterina.kantserova at oracle.com > Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com,christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com > Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien > ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd > > This looks a lot better. Just few more comments: > > ToolConfig.java > L72 - "getToolOptins" -> "getToolOptions" > L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. > > Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? > > > Thanks, > /Staffan > > > On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: > > Hi, > > I've done following big changes after the Staffan's review: > - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig > - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM > - tools will be launched without -vmoptions > > plus made fixes for all minor comments. > > If it's a good idea to push testlibrary changes separately I can make a separate patch for them. > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja > > > > On 10/23/2013 12:55 PM, Staffan Larsen wrote: > test/lib/testlibrary/jdk/testlibrary/Asserts.java > Same code as already exists in the hotspot testlibrary. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/ProcessThread.java > L33: stating -> starting > L66: staring -> starting > > > test/lib/testlibrary/jdk/testlibrary/TestThread.java > This code comes from an internal test library. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/Utils.java > No comments. > > > test/lib/testlibrary/jdk/testlibrary/XRun.java > This code comes from an internal test library. > No further comments. > > > test/sun/tools/jstatd/JstatGcutilParser.java > The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. > > I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? > > L67: getType() should be private. > > > test/sun/tools/jstatd/JstatdHelper.java: > L54: Does verifyJpsOutput() work correctly with output of the form: > > 1234 -- main class information unavailable > 1235 -- process information unavailable > > Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. > > L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? > > > test/sun/tools/jstatd/TestJstatdDefaults.java > test/sun/tools/jstatd/TestJstatdExternalRegistry.java > test/sun/tools/jstatd/TestJstatdPort.java > test/sun/tools/jstatd/TestJstatdPortAndServer.java > test/sun/tools/jstatd/TestJstatdServer.java > No comments. > > > test/sun/tools/jstatd/TestJstatdUsage.java > Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. > > > test/sun/tools/jstatd/ToolConfig.java > ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? > > You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? > > > General comments: > > Can't we do: > * @library /lib/testlibrary > instead of > * @library ../../../lib/testlibrary > ? > > It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. > > While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. > > > Thanks, > /Staffan From alejandro.murillo at oracle.com Mon Oct 28 10:43:56 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Mon, 28 Oct 2013 17:43:56 +0000 Subject: hg: hsx/hotspot-main/hotspot: 19 new changesets Message-ID: <20131028174448.B8FAB6279E@hg.openjdk.java.net> Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 1a93f2c5945a Author: lana Date: 2013-10-17 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a93f2c5945a Merge ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! src/share/vm/classfile/classFileParser.cpp Changeset: 4589b398ab03 Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4589b398ab03 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 4a1128861221 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a1128861221 Added tag jdk8-b113 for changeset 4589b398ab03 ! .hgtags Changeset: 82a9cdbf683e Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/82a9cdbf683e Merge ! src/share/vm/services/diagnosticCommand.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: bde83ddf920c Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bde83ddf920c Added tag hs25-b56 for changeset 82a9cdbf683e ! .hgtags Changeset: f94a9f0746d8 Author: amurillo Date: 2013-10-25 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f94a9f0746d8 8027173: new hotspot build - hs25-b57 Reviewed-by: jcoomes ! make/hotspot_version From francis.andre.kampbell at orange.fr Mon Oct 28 11:17:37 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Mon, 28 Oct 2013 19:17:37 +0100 Subject: -Xint: template or c++ interpreter? In-Reply-To: <92AF990A-4FFE-444B-A8DA-00795F2BC424@oracle.com> References: <526C23EE.6090803@orange.fr> <526D2999.2040205@orange.fr> <526D5E4D.2030603@orange.fr> <92AF990A-4FFE-444B-A8DA-00795F2BC424@oracle.com> Message-ID: <526EAA41.5020306@orange.fr> Bob Le 28/10/2013 15:18, Bob Vandette a ?crit : > I don't think we'd want to change the version string to include this type of implementation specific detail. > > If this is just for testing, how about looking for symbols specific to the interpreter implementation in the JVM? The purpose is to provide an evidence that the interpreter is the template based or the cpp based interpreter -- I am working to align the cpp interpreter on WXP/Cygwin/VS2010 and with the patches I will provide also the jtreg test reports for proving that the cpp interpreter is working -- but I need a way to identify the cpp interpreter as simple string somewhere in the jtreg report. I was thinking that a slight change to the -version option would be accepted. So how could be provided this information? Through an addition keyword? Francis > > nm -C libjvm.so | grep TemplateTable::initialize > > or > > nm -C libjvm.so | grep CppInterpreter::initialize > > Bob. > > > On Oct 27, 2013, at 2:41 PM, Francis ANDRE wrote: > >> Hi Volker >> >> Le 27/10/2013 18:06, Volker Simonis a ?crit : >>> Hi Francis, >>> >>> as Bob pointed out, choosing the C++ vs. the Template Interpreter is >>> currently a compile time decision. And I think >>> it won't be easy to change that, because you will probably get name >>> clashes with the current source code. >> I have no problem with the decision of choosing the C++ vs the template interpreter at compile time. My initial question was related to the fact that the hotspot code is relatively complex to understand at large and I wanted to be sure of running either the cpp interpreter either the template interpreter with may be an additional internal parameter. So the define CC_INTERP makes the choice and that's ok. >>> Regards, >>> Volker >>> >>> PS: by the way, your example is still compile time. >> Yes, it is compile time but that information is produced running java -version and would be useful as a tracker of which interpreter is used. I want to identify the interpreter used in the jdk jtreg tests to avoid uncertainty. >> >> Francis >>> On Sun, Oct 27, 2013 at 3:56 PM, Francis ANDRE >>> wrote: >>>> Bob >>>> >>>> I would like to distinguished at run time the kind of interpreter used. >>>> Would something like that be acceptable or is there another way to publish >>>> it? (may be the wording is bad, but that's an idea). >>>> >>>> const char* Abstract_VM_Version::vm_info_string() { >>>> switch (Arguments::mode()) { >>>> case Arguments::_int: >>>> #ifdef CC_INTERP >>>> return UseSharedSpaces ? "code base interpreted mode, sharing" : "code >>>> base interpreted mode"; >>>> #else >>>> return UseSharedSpaces ? "template interpreted mode, sharing" : >>>> "template interpreted mode"; >>>> #endif // CC_INTERP >>>> case Arguments::_mixed: >>>> return UseSharedSpaces ? "mixed mode, sharing" : "mixed mode"; >>>> case Arguments::_comp: >>>> return UseSharedSpaces ? "compiled mode, sharing" : "compiled >>>> mode"; >>>> }; >>>> >>>> Francis >>>> >>>> Le 26/10/2013 23:27, Bob Vandette a ?crit : >>>> >>>>> Compiling Hotspot with CC_INTERP does exclude the template interpreter. >>>>> You either build a template Interpreter or C++ Interpreter. >>>>> >>>>> Bob. >>>>> >>>>> On Oct 26, 2013, at 4:19 PM, Francis ANDRE >>>>> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> The -Xint option specifies to the JVM to run only in interpreted mode, >>>>>> but since compiling the JVM with CC_INTERP do not exclude the template >>>>>> Interpreter, I am wondering if there is an option to specify that only the >>>>>> template Interpreter or only the C++ Interpreter be used? >>>>>> >>>>>> Francis > From david.holmes at oracle.com Mon Oct 28 18:10:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Oct 2013 11:10:30 +1000 Subject: -Xint: template or c++ interpreter? In-Reply-To: <526EAA41.5020306@orange.fr> References: <526C23EE.6090803@orange.fr> <526D2999.2040205@orange.fr> <526D5E4D.2030603@orange.fr> <92AF990A-4FFE-444B-A8DA-00795F2BC424@oracle.com> <526EAA41.5020306@orange.fr> Message-ID: <526F0B06.20504@oracle.com> Francis, On 29/10/2013 4:17 AM, Francis ANDRE wrote: > Bob > > Le 28/10/2013 15:18, Bob Vandette a ?crit : >> I don't think we'd want to change the version string to include this >> type of implementation specific detail. >> >> If this is just for testing, how about looking for symbols specific to >> the interpreter implementation in the JVM? > The purpose is to provide an evidence that the interpreter is the > template based or the cpp based interpreter -- I am working to align the > cpp interpreter on WXP/Cygwin/VS2010 and with the patches I will provide > also the jtreg test reports for proving that the cpp interpreter is > working -- but I need a way to identify the cpp interpreter as simple > string somewhere in the jtreg report. I was thinking that a slight > change to the -version option would be accepted. So how could be > provided this information? Through an addition keyword? You can set your own version string as part of the build process, so you could select something to identify a template interpreter build versus a cpp interpreter build. Simplest variable to hijack would be the MILESTONE setting. I set it to testing and now see: java version "1.8.0-testing" Java(TM) SE Runtime Environment (build 1.8.0-testing-b112) Java HotSpot(TM) Server VM (build 25.0-b54, mixed mode) but if you want to modify the Hotspot part that can be done too. Eg HOTSPOT_VM_DISTRO controls the "Java HotSpot(TM)" part above (for Oracle JDK build, an OpenJDK build has different info) so you could augment that. HTH. David > Francis >> >> nm -C libjvm.so | grep TemplateTable::initialize >> >> or >> >> nm -C libjvm.so | grep CppInterpreter::initialize >> >> Bob. >> >> >> On Oct 27, 2013, at 2:41 PM, Francis ANDRE >> wrote: >> >>> Hi Volker >>> >>> Le 27/10/2013 18:06, Volker Simonis a ?crit : >>>> Hi Francis, >>>> >>>> as Bob pointed out, choosing the C++ vs. the Template Interpreter is >>>> currently a compile time decision. And I think >>>> it won't be easy to change that, because you will probably get name >>>> clashes with the current source code. >>> I have no problem with the decision of choosing the C++ vs the >>> template interpreter at compile time. My initial question was related >>> to the fact that the hotspot code is relatively complex to understand >>> at large and I wanted to be sure of running either the cpp >>> interpreter either the template interpreter with may be an additional >>> internal parameter. So the define CC_INTERP makes the choice and >>> that's ok. >>>> Regards, >>>> Volker >>>> >>>> PS: by the way, your example is still compile time. >>> Yes, it is compile time but that information is produced running java >>> -version and would be useful as a tracker of which interpreter is >>> used. I want to identify the interpreter used in the jdk jtreg tests >>> to avoid uncertainty. >>> >>> Francis >>>> On Sun, Oct 27, 2013 at 3:56 PM, Francis ANDRE >>>> wrote: >>>>> Bob >>>>> >>>>> I would like to distinguished at run time the kind of interpreter >>>>> used. >>>>> Would something like that be acceptable or is there another way to >>>>> publish >>>>> it? (may be the wording is bad, but that's an idea). >>>>> >>>>> const char* Abstract_VM_Version::vm_info_string() { >>>>> switch (Arguments::mode()) { >>>>> case Arguments::_int: >>>>> #ifdef CC_INTERP >>>>> return UseSharedSpaces ? "code base interpreted mode, >>>>> sharing" : "code >>>>> base interpreted mode"; >>>>> #else >>>>> return UseSharedSpaces ? "template interpreted mode, sharing" : >>>>> "template interpreted mode"; >>>>> #endif // CC_INTERP >>>>> case Arguments::_mixed: >>>>> return UseSharedSpaces ? "mixed mode, sharing" : >>>>> "mixed mode"; >>>>> case Arguments::_comp: >>>>> return UseSharedSpaces ? "compiled mode, sharing" : >>>>> "compiled >>>>> mode"; >>>>> }; >>>>> >>>>> Francis >>>>> >>>>> Le 26/10/2013 23:27, Bob Vandette a ?crit : >>>>> >>>>>> Compiling Hotspot with CC_INTERP does exclude the template >>>>>> interpreter. >>>>>> You either build a template Interpreter or C++ Interpreter. >>>>>> >>>>>> Bob. >>>>>> >>>>>> On Oct 26, 2013, at 4:19 PM, Francis ANDRE >>>>>> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> The -Xint option specifies to the JVM to run only in interpreted >>>>>>> mode, >>>>>>> but since compiling the JVM with CC_INTERP do not exclude the >>>>>>> template >>>>>>> Interpreter, I am wondering if there is an option to specify that >>>>>>> only the >>>>>>> template Interpreter or only the C++ Interpreter be used? >>>>>>> >>>>>>> Francis >> > From vladimir.kozlov at oracle.com Tue Oct 29 14:17:04 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 29 Oct 2013 21:17:04 +0000 Subject: hg: hsx/jdk7u/hotspot: 8026293: Schedule part of G1 pre-barrier late Message-ID: <20131029211727.B9F7062803@hg.openjdk.java.net> Changeset: af2cdb805b16 Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/af2cdb805b16 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp From mikael.gerdin at oracle.com Wed Oct 30 01:45:07 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 30 Oct 2013 09:45:07 +0100 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <1828254.FSQ7MTpyjg@mgerdin03> References: <1828254.FSQ7MTpyjg@mgerdin03> Message-ID: <1848253.uninkEqy8m@mgerdin03> Hi, So far I've only gotten a review from Coleen on this fix. Unless anyone is opposed to pushing this fix, regardless of what we do about the possible triggering changes for this, I'd still like to push this. /Mikael On Friday 25 October 2013 17.55.10 Mikael Gerdin wrote: > Hi all, > > Initially I'd like to hear people's opinions on this issue. It appears to > have surfaced after we've reduced the unnecessary alignment "cushions" for > metaspace together with the fact that we are now always able to use the > very last bit of a VirtualSpace (in Metaspace). > > The issue is extremely difficult to reproduce, because it relies on the > exact order and size of all metaspace allocations for a run to trigger this > problem. > > Description of the problem: > > We recently had some mysterious crashes in the GC testing, and I narrowed > them down to the following scenario: > > Imagine that we have a VirtualSpace (for Metaspace) > [ | bb] > ConstMethod > > And that the very last object allocated in such a space is a ConstMethod, > and that it has its embedded bytecodes filling up to the very end. > > Consider the case when the second last bytecode (the one before "Xreturn") > is one with an embedded 2-byte index (a constant pool or local variable > index) for example: > - (bcp) checkcast #6 0xc0 0x00 0x06 > - (bcp+3) areturn 0xb0 > - (bcp+4) UNMAPPED MEMORY > > The template interpreter here uses a 4-byte load on intel to read the index > embedded in the checkcast: > mov 0x1(%esi),%ebx > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > > I looked through the code for places where we do similar loads of 2-byte > indexes and found the same problem for iload_w: > 0xe73f7fbb: mov 0x2(%esi),%ebx > 0xe73f7fbe: bswap %ebx > 0xe73f7fc0: shr $0x10,%ebx > > I looked through most places where we emit > __ movl > __ bswap > and changed the places I could find which were affected. > > Suggested fix: > Replace movl with load_[un]signed_short in the places where we load 2-byte > values from the byte code stream. > I've verified that load_unsigned_short (which boils down to movzwl, opcodes > 0x0f 0xb7 only reads 2 bytes). > > Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 > Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ > > Testing: > vm.quick.testlist -Xint on linux-i586 and x86_64(running) > > Thanks > /Mikael From yekaterina.kantserova at oracle.com Wed Oct 30 02:27:41 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 30 Oct 2013 10:27:41 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> Message-ID: <5270D10D.1060201@oracle.com> http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ Fixed your points and changed ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher instead of JDKFinder. Thanks, Katja On 10/28/2013 07:02 PM, Staffan Larsen wrote: > Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). > > nit: JstatdTest.cleanUpThread() shouldn't be static. > > Thanks, > /Staffan > > On 28 okt 2013, at 17:12, Yekaterina Kantserova > > wrote: > >> Hi, >> >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >> >> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) >> and deleted ToolConfig. The tests are also changed a little: >> >> public class TestJstatdDefaults { >> >> public static void main(String[] args) throws Throwable { >> JstatdTest test = new JstatdTest(); >> test.doTest(); >> } >> >> } >> >> Hope it looks better now. >> >> Thanks, >> Katja >> >> ----- Ursprungligt meddelande ----- >> Fr?n:staffan.larsen at oracle.com >> Till:yekaterina.kantserova at oracle.com >> >> Kopia: serviceability-dev at openjdk.java.net >> ,david.holmes at oracle.com >> ,jaroslav.bachorik at oracle.com >> ,christian.tornqvist at oracle.com >> , hotspot-dev at openjdk.java.net >> ,mattis.castegren at oracle.com >> >> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 >> Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >> ?mne: Re: RFR (S): 8022229: Intermittent test failures in >> sun/tools/jstatd >> >> This looks a lot better. Just few more comments: >> >> ToolConfig.java >> L72 - "getToolOptins" -> "getToolOptions" >> L35 - why is port stored as a String? Also, could be renamed to >> rmiRegistryPort to clarify what it is for. >> >> Why are some tool-specific options added in getToolOptins() and >> some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe >> changing getToolOptins() to only return the host part of the options >> and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >> >> >> Thanks, >> /Staffan >> >> >> On 24 okt 2013, at 15:57, Yekaterina Kantserova >> > > wrote: >> >> Hi, >> >> I've done following big changes after the Staffan's review: >> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot >> testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) >> for re-using in ToolConfig >> - changed "verifiy output form jps, jstat"-methods to ignore >> warnings from VM >> - tools will be launched without -vmoptions >> >> plusmade fixes for all minorcomments. >> >> If it's a good idea to push testlibrary changes separately I can >> make a separate patch for them. >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similarbugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 >> >> Thanks, >> Katja >> >> >> >> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >> >> test/lib/testlibrary/jdk/testlibrary/Asserts.java >> Same code as already exists in the hotspot testlibrary. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >> L33: stating -> starting >> L66: staring -> starting >> >> >> test/lib/testlibrary/jdk/testlibrary/TestThread.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/Utils.java >> No comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/XRun.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/sun/tools/jstatd/JstatGcutilParser.java >> The parse() method could be made more robust by discarding >> any lines that come before the header lines. This can happen >> if the JVM outputs a warning message for some reason before >> running jstat. >> I don't like the special-case for the CCS column in >> verify() - took me a while to find it. Should we add a new >> enum called PERCENTAGE_OR_DASH to handle that instead? >> >> L67: getType() should be private. >> >> >> test/sun/tools/jstatd/JstatdHelper.java: >> L54: Does verifyJpsOutput() work correctly with output of >> the form: >> >> 1234 -- main class information unavailable >> 1235 -- process information unavailable >> >> Also: same comment here as for JstatGcutilParser.java: >> sometimes the JVM outputs warning messages before the output >> from the tool. >> >> L46: "attach" is probably not the best way to describe the >> operation of jps. It does not attach to the process, it >> merely lists the running processes. Perhaps runJps() is a >> better name? >> >> >> test/sun/tools/jstatd/TestJstatdDefaults.java >> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >> test/sun/tools/jstatd/TestJstatdPort.java >> test/sun/tools/jstatd/TestJstatdPortAndServer.java >> test/sun/tools/jstatd/TestJstatdServer.java >> No comments. >> >> >> test/sun/tools/jstatd/TestJstatdUsage.java >> Same comment here as for JstatGcutilParser.java: sometimes >> the JVM outputs warning messages before the output from the tool. >> >> >> test/sun/tools/jstatd/ToolConfig.java >> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing >> similar things to JDKToolLauncher in the hotspot testlibrary. >> It is unfortunate if we have two ways to do similar things in >> the two different testlibraries. Would it be possible to >> reuse the hotspot code here instead? >> >> You have also changed the test. Previously the tools were >> not launched with the jtreg -vmoptions (test.vm.opts), >> whereas now they will be. Is this intentional? >> >> >> General comments: >> >> Can't we do: >> * @library /lib/testlibrary >> instead of >> * @library ../../../lib/testlibrary >> ? >> >> It seems that at least some of the functionality should be >> reused for re-writing the jstat and jps tests as well. I >> guess we can look at that at a later time, though. >> >> While I applaud the move from shell scripts to Java code, I >> can't shake the feeling that the shell scripts were easier to >> read and follow. The Java code is much more verbose and >> spread out over multiple helpers and libraries, making it >> harder to grasp. That may be the price we have to pay, though. >> >> >> Thanks, >> /Staffan >> > From serguei.spitsyn at oracle.com Wed Oct 30 02:35:08 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Oct 2013 02:35:08 -0700 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <1848253.uninkEqy8m@mgerdin03> References: <1828254.FSQ7MTpyjg@mgerdin03> <1848253.uninkEqy8m@mgerdin03> Message-ID: <5270D2CC.5080405@oracle.com> Hi Mikael, Interesting investigation! The fix looks good. Thanks, Serguei On 10/30/13 1:45 AM, Mikael Gerdin wrote: > Hi, > > So far I've only gotten a review from Coleen on this fix. > Unless anyone is opposed to pushing this fix, regardless of what we do about > the possible triggering changes for this, I'd still like to push this. > > /Mikael > > On Friday 25 October 2013 17.55.10 Mikael Gerdin wrote: >> Hi all, >> >> Initially I'd like to hear people's opinions on this issue. It appears to >> have surfaced after we've reduced the unnecessary alignment "cushions" for >> metaspace together with the fact that we are now always able to use the >> very last bit of a VirtualSpace (in Metaspace). >> >> The issue is extremely difficult to reproduce, because it relies on the >> exact order and size of all metaspace allocations for a run to trigger this >> problem. >> >> Description of the problem: >> >> We recently had some mysterious crashes in the GC testing, and I narrowed >> them down to the following scenario: >> >> Imagine that we have a VirtualSpace (for Metaspace) >> [ | bb] >> ConstMethod >> >> And that the very last object allocated in such a space is a ConstMethod, >> and that it has its embedded bytecodes filling up to the very end. >> >> Consider the case when the second last bytecode (the one before "Xreturn") >> is one with an embedded 2-byte index (a constant pool or local variable >> index) for example: >> - (bcp) checkcast #6 0xc0 0x00 0x06 >> - (bcp+3) areturn 0xb0 >> - (bcp+4) UNMAPPED MEMORY >> >> The template interpreter here uses a 4-byte load on intel to read the index >> embedded in the checkcast: >> mov 0x1(%esi),%ebx >> this will read the bytes [bcp+1,bcp+4] and cause a SEGV. >> >> I looked through the code for places where we do similar loads of 2-byte >> indexes and found the same problem for iload_w: >> 0xe73f7fbb: mov 0x2(%esi),%ebx >> 0xe73f7fbe: bswap %ebx >> 0xe73f7fc0: shr $0x10,%ebx >> >> I looked through most places where we emit >> __ movl >> __ bswap >> and changed the places I could find which were affected. >> >> Suggested fix: >> Replace movl with load_[un]signed_short in the places where we load 2-byte >> values from the byte code stream. >> I've verified that load_unsigned_short (which boils down to movzwl, opcodes >> 0x0f 0xb7 only reads 2 bytes). >> >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ >> >> Testing: >> vm.quick.testlist -Xint on linux-i586 and x86_64(running) >> >> Thanks >> /Mikael From mikael.gerdin at oracle.com Wed Oct 30 02:40:02 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 30 Oct 2013 10:40:02 +0100 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <5270D2CC.5080405@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <1848253.uninkEqy8m@mgerdin03> <5270D2CC.5080405@oracle.com> Message-ID: <3084548.UF5i315lyt@mgerdin03> Serguei, On Wednesday 30 October 2013 02.35.08 serguei.spitsyn at oracle.com wrote: > Hi Mikael, > > Interesting investigation! > The fix looks good. Thanks for the review! /Mikael > > Thanks, > Serguei > > On 10/30/13 1:45 AM, Mikael Gerdin wrote: > > Hi, > > > > So far I've only gotten a review from Coleen on this fix. > > Unless anyone is opposed to pushing this fix, regardless of what we do > > about the possible triggering changes for this, I'd still like to push > > this. > > > > /Mikael > > > > On Friday 25 October 2013 17.55.10 Mikael Gerdin wrote: > >> Hi all, > >> > >> Initially I'd like to hear people's opinions on this issue. It appears to > >> have surfaced after we've reduced the unnecessary alignment "cushions" > >> for > >> metaspace together with the fact that we are now always able to use the > >> very last bit of a VirtualSpace (in Metaspace). > >> > >> The issue is extremely difficult to reproduce, because it relies on the > >> exact order and size of all metaspace allocations for a run to trigger > >> this > >> problem. > >> > >> Description of the problem: > >> > >> We recently had some mysterious crashes in the GC testing, and I narrowed > >> them down to the following scenario: > >> > >> Imagine that we have a VirtualSpace (for Metaspace) > >> [ | bb] > >> > >> ConstMethod > >> > >> And that the very last object allocated in such a space is a ConstMethod, > >> and that it has its embedded bytecodes filling up to the very end. > >> > >> Consider the case when the second last bytecode (the one before > >> "Xreturn") > >> is one with an embedded 2-byte index (a constant pool or local variable > >> index) for example: > >> - (bcp) checkcast #6 0xc0 0x00 0x06 > >> - (bcp+3) areturn 0xb0 > >> - (bcp+4) UNMAPPED MEMORY > >> > >> The template interpreter here uses a 4-byte load on intel to read the > >> index > >> embedded in the checkcast: > >> mov 0x1(%esi),%ebx > >> this will read the bytes [bcp+1,bcp+4] and cause a SEGV. > >> > >> I looked through the code for places where we do similar loads of 2-byte > >> > >> indexes and found the same problem for iload_w: > >> 0xe73f7fbb: mov 0x2(%esi),%ebx > >> 0xe73f7fbe: bswap %ebx > >> 0xe73f7fc0: shr $0x10,%ebx > >> > >> I looked through most places where we emit > >> __ movl > >> __ bswap > >> and changed the places I could find which were affected. > >> > >> Suggested fix: > >> Replace movl with load_[un]signed_short in the places where we load > >> 2-byte > >> values from the byte code stream. > >> I've verified that load_unsigned_short (which boils down to movzwl, > >> opcodes > >> 0x0f 0xb7 only reads 2 bytes). > >> > >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 > >> Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ > >> > >> Testing: > >> vm.quick.testlist -Xint on linux-i586 and x86_64(running) > >> > >> Thanks > >> /Mikael From staffan.larsen at oracle.com Wed Oct 30 02:56:36 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 10:56:36 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <5270D10D.1060201@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> <5270D10D.1060201@oracle.com> Message-ID: <43432737-E1A3-433D-B2BD-3A7A07B57485@oracle.com> Looks good! Reviewed. Thanks, /Staffan On 30 okt 2013, at 10:27, Yekaterina Kantserova wrote: > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ > > Fixed your points and changed ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher instead of JDKFinder. > > Thanks, > Katja > > > On 10/28/2013 07:02 PM, Staffan Larsen wrote: >> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). >> >> nit: JstatdTest.cleanUpThread() shouldn't be static. >> >> Thanks, >> /Staffan >> >> On 28 okt 2013, at 17:12, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >>> >>> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: >>> >>> public class TestJstatdDefaults { >>> >>> public static void main(String[] args) throws Throwable { >>> JstatdTest test = new JstatdTest(); >>> test.doTest(); >>> } >>> >>> } >>> >>> Hope it looks better now. >>> >>> Thanks, >>> Katja >>> >>> ----- Ursprungligt meddelande ----- >>> Fr?n: staffan.larsen at oracle.com >>> Till: yekaterina.kantserova at oracle.com >>> Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com,christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com >>> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >>> ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd >>> >>> This looks a lot better. Just few more comments: >>> >>> ToolConfig.java >>> L72 - "getToolOptins" -> "getToolOptions" >>> L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. >>> >>> Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: >>> >>> Hi, >>> >>> I've done following big changes after the Staffan's review: >>> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig >>> - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM >>> - tools will be launched without -vmoptions >>> >>> plus made fixes for all minor comments. >>> >>> If it's a good idea to push testlibrary changes separately I can make a separate patch for them. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >>> >>> Primal bug: >>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>> >>> Similar bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>> https://bugs.openjdk.java.net/browse/JDK-6543979 >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >>> test/lib/testlibrary/jdk/testlibrary/Asserts.java >>> Same code as already exists in the hotspot testlibrary. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >>> L33: stating -> starting >>> L66: staring -> starting >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/TestThread.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>> No comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/XRun.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/sun/tools/jstatd/JstatGcutilParser.java >>> The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. >>> >>> I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? >>> >>> L67: getType() should be private. >>> >>> >>> test/sun/tools/jstatd/JstatdHelper.java: >>> L54: Does verifyJpsOutput() work correctly with output of the form: >>> >>> 1234 -- main class information unavailable >>> 1235 -- process information unavailable >>> >>> Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>> >>> L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? >>> >>> >>> test/sun/tools/jstatd/TestJstatdDefaults.java >>> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >>> test/sun/tools/jstatd/TestJstatdPort.java >>> test/sun/tools/jstatd/TestJstatdPortAndServer.java >>> test/sun/tools/jstatd/TestJstatdServer.java >>> No comments. >>> >>> >>> test/sun/tools/jstatd/TestJstatdUsage.java >>> Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>> >>> >>> test/sun/tools/jstatd/ToolConfig.java >>> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? >>> >>> You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? >>> >>> >>> General comments: >>> >>> Can't we do: >>> * @library /lib/testlibrary >>> instead of >>> * @library ../../../lib/testlibrary >>> ? >>> >>> It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. >>> >>> While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. >>> >>> >>> Thanks, >>> /Staffan >> > > <8022229.4.patch> From yekaterina.kantserova at oracle.com Wed Oct 30 06:31:38 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 30 Oct 2013 14:31:38 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <5270D10D.1060201@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> <5270D10D.1060201@oracle.com> Message-ID: <52710A3A.8070409@oracle.com> I've forgot to mention one more fix. I've renamed JstatGcutilParser to JstatGCUtilParser (a tip from Erik), to follow standards in testlibrary (JDKToolLauncher, not JdkToolLauncher). Here is a new webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.05/ The tests have passed in JPRT run: http://sthjprt.se.oracle.com/archives/2013/10/2013-10-30-120951.ykantser.tl/ The attached patch is ready to be pushed. Staffan, Erik, Jaroslav, Peter: thanks a lot for your time and patient, Katja On 10/30/2013 10:27 AM, Yekaterina Kantserova wrote: > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ > > Fixed your points and changed > ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher > instead of JDKFinder. > > Thanks, > Katja > > > On 10/28/2013 07:02 PM, Staffan Larsen wrote: >> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). >> >> nit: JstatdTest.cleanUpThread() shouldn't be static. >> >> Thanks, >> /Staffan >> >> On 28 okt 2013, at 17:12, Yekaterina Kantserova >> > > wrote: >> >>> Hi, >>> >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >>> >>> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) >>> and deleted ToolConfig. The tests are also changed a little: >>> >>> public class TestJstatdDefaults { >>> >>> public static void main(String[] args) throws Throwable { >>> JstatdTest test = new JstatdTest(); >>> test.doTest(); >>> } >>> >>> } >>> >>> Hope it looks better now. >>> >>> Thanks, >>> Katja >>> >>> ----- Ursprungligt meddelande ----- >>> Fr?n:staffan.larsen at oracle.com >>> Till:yekaterina.kantserova at oracle.com >>> >>> Kopia: serviceability-dev at openjdk.java.net >>> ,david.holmes at oracle.com >>> ,jaroslav.bachorik at oracle.com >>> ,christian.tornqvist at oracle.com >>> , >>> hotspot-dev at openjdk.java.net >>> ,mattis.castegren at oracle.com >>> >>> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 >>> Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >>> ?mne: Re: RFR (S): 8022229: Intermittent test failures in >>> sun/tools/jstatd >>> >>> This looks a lot better. Just few more comments: >>> >>> ToolConfig.java >>> L72 - "getToolOptins" -> "getToolOptions" >>> L35 - why is port stored as a String? Also, could be renamed to >>> rmiRegistryPort to clarify what it is for. >>> >>> Why are some tool-specific options added in getToolOptins() and >>> some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe >>> changing getToolOptins() to only return the host part of the options >>> and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 24 okt 2013, at 15:57, Yekaterina Kantserova >>> >> > wrote: >>> >>> Hi, >>> >>> I've done following big changes after the Staffan's review: >>> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot >>> testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) >>> for re-using in ToolConfig >>> - changed "verifiy output form jps, jstat"-methods to ignore >>> warnings from VM >>> - tools will be launched without -vmoptions >>> >>> plusmade fixes for all minorcomments. >>> >>> If it's a good idea to push testlibrary changes separately I can >>> make a separate patch for them. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >>> >>> Primal bug: >>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>> >>> Similarbugs: >>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>> https://bugs.openjdk.java.net/browse/JDK-6543979 >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >>> >>> test/lib/testlibrary/jdk/testlibrary/Asserts.java >>> Same code as already exists in the hotspot testlibrary. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >>> L33: stating -> starting >>> L66: staring -> starting >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/TestThread.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>> No comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/XRun.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/sun/tools/jstatd/JstatGcutilParser.java >>> The parse() method could be made more robust by discarding >>> any lines that come before the header lines. This can happen >>> if the JVM outputs a warning message for some reason before >>> running jstat. >>> I don't like the special-case for the CCS column in >>> verify() - took me a while to find it. Should we add a new >>> enum called PERCENTAGE_OR_DASH to handle that instead? >>> >>> L67: getType() should be private. >>> >>> >>> test/sun/tools/jstatd/JstatdHelper.java: >>> L54: Does verifyJpsOutput() work correctly with output of >>> the form: >>> >>> 1234 -- main class information unavailable >>> 1235 -- process information unavailable >>> >>> Also: same comment here as for JstatGcutilParser.java: >>> sometimes the JVM outputs warning messages before the output >>> from the tool. >>> >>> L46: "attach" is probably not the best way to describe the >>> operation of jps. It does not attach to the process, it >>> merely lists the running processes. Perhaps runJps() is a >>> better name? >>> >>> >>> test/sun/tools/jstatd/TestJstatdDefaults.java >>> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >>> test/sun/tools/jstatd/TestJstatdPort.java >>> test/sun/tools/jstatd/TestJstatdPortAndServer.java >>> test/sun/tools/jstatd/TestJstatdServer.java >>> No comments. >>> >>> >>> test/sun/tools/jstatd/TestJstatdUsage.java >>> Same comment here as for JstatGcutilParser.java: sometimes >>> the JVM outputs warning messages before the output from the >>> tool. >>> >>> >>> test/sun/tools/jstatd/ToolConfig.java >>> ToolConfig + Utils.get(Forward)VmOptions() seem to be >>> doing similar things to JDKToolLauncher in the hotspot >>> testlibrary. It is unfortunate if we have two ways to do >>> similar things in the two different testlibraries. Would it >>> be possible to reuse the hotspot code here instead? >>> >>> You have also changed the test. Previously the tools were >>> not launched with the jtreg -vmoptions (test.vm.opts), >>> whereas now they will be. Is this intentional? >>> >>> >>> General comments: >>> >>> Can't we do: >>> * @library /lib/testlibrary >>> instead of >>> * @library ../../../lib/testlibrary >>> ? >>> >>> It seems that at least some of the functionality should be >>> reused for re-writing the jstat and jps tests as well. I >>> guess we can look at that at a later time, though. >>> >>> While I applaud the move from shell scripts to Java code, I >>> can't shake the feeling that the shell scripts were easier >>> to read and follow. The Java code is much more verbose and >>> spread out over multiple helpers and libraries, making it >>> harder to grasp. That may be the price we have to pay, though. >>> >>> >>> Thanks, >>> /Staffan >>> >> > From staffan.larsen at oracle.com Wed Oct 30 08:01:30 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 16:01:30 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <52710A3A.8070409@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> <5270D10D.1060201@oracle.com> <52710A3A.8070409@oracle.com> Message-ID: Looks good. I will sponsor the commit. Thanks, /Staffan On 30 okt 2013, at 14:31, Yekaterina Kantserova wrote: > I've forgot to mention one more fix. I've renamed JstatGcutilParser to JstatGCUtilParser (a tip from Erik), to follow standards in testlibrary (JDKToolLauncher, not JdkToolLauncher). > > Here is a new webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.05/ > > The tests have passed in JPRT run: > http://sthjprt.se.oracle.com/archives/2013/10/2013-10-30-120951.ykantser.tl/ > > The attached patch is ready to be pushed. > > > Staffan, Erik, Jaroslav, Peter: thanks a lot for your time and patient, > Katja > > > > On 10/30/2013 10:27 AM, Yekaterina Kantserova wrote: >> >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ >> >> Fixed your points and changed ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher instead of JDKFinder. >> >> Thanks, >> Katja >> >> >> On 10/28/2013 07:02 PM, Staffan Larsen wrote: >>> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). >>> >>> nit: JstatdTest.cleanUpThread() shouldn't be static. >>> >>> Thanks, >>> /Staffan >>> >>> On 28 okt 2013, at 17:12, Yekaterina Kantserova wrote: >>> >>>> Hi, >>>> >>>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >>>> >>>> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: >>>> >>>> public class TestJstatdDefaults { >>>> >>>> public static void main(String[] args) throws Throwable { >>>> JstatdTest test = new JstatdTest(); >>>> test.doTest(); >>>> } >>>> >>>> } >>>> >>>> Hope it looks better now. >>>> >>>> Thanks, >>>> Katja >>>> >>>> ----- Ursprungligt meddelande ----- >>>> Fr?n: staffan.larsen at oracle.com >>>> Till: yekaterina.kantserova at oracle.com >>>> Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com,christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com >>>> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >>>> ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd >>>> >>>> This looks a lot better. Just few more comments: >>>> >>>> ToolConfig.java >>>> L72 - "getToolOptins" -> "getToolOptions" >>>> L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. >>>> >>>> Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: >>>> >>>> Hi, >>>> >>>> I've done following big changes after the Staffan's review: >>>> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig >>>> - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM >>>> - tools will be launched without -vmoptions >>>> >>>> plus made fixes for all minor comments. >>>> >>>> If it's a good idea to push testlibrary changes separately I can make a separate patch for them. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >>>> >>>> Primal bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>>> >>>> Similar bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>>> https://bugs.openjdk.java.net/browse/JDK-6543979 >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> >>>> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >>>> test/lib/testlibrary/jdk/testlibrary/Asserts.java >>>> Same code as already exists in the hotspot testlibrary. >>>> No further comments. >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >>>> L33: stating -> starting >>>> L66: staring -> starting >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/TestThread.java >>>> This code comes from an internal test library. >>>> No further comments. >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>>> No comments. >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/XRun.java >>>> This code comes from an internal test library. >>>> No further comments. >>>> >>>> >>>> test/sun/tools/jstatd/JstatGcutilParser.java >>>> The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. >>>> >>>> I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? >>>> >>>> L67: getType() should be private. >>>> >>>> >>>> test/sun/tools/jstatd/JstatdHelper.java: >>>> L54: Does verifyJpsOutput() work correctly with output of the form: >>>> >>>> 1234 -- main class information unavailable >>>> 1235 -- process information unavailable >>>> >>>> Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>>> >>>> L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? >>>> >>>> >>>> test/sun/tools/jstatd/TestJstatdDefaults.java >>>> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >>>> test/sun/tools/jstatd/TestJstatdPort.java >>>> test/sun/tools/jstatd/TestJstatdPortAndServer.java >>>> test/sun/tools/jstatd/TestJstatdServer.java >>>> No comments. >>>> >>>> >>>> test/sun/tools/jstatd/TestJstatdUsage.java >>>> Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>>> >>>> >>>> test/sun/tools/jstatd/ToolConfig.java >>>> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? >>>> >>>> You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? >>>> >>>> >>>> General comments: >>>> >>>> Can't we do: >>>> * @library /lib/testlibrary >>>> instead of >>>> * @library ../../../lib/testlibrary >>>> ? >>>> >>>> It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. >>>> >>>> While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. >>>> >>>> >>>> Thanks, >>>> /Staffan >>> >> > > <8022229.5.patch> From calvin.cheung at oracle.com Wed Oct 30 16:27:10 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Wed, 30 Oct 2013 23:27:10 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20131030232805.8639C62851@hg.openjdk.java.net> Changeset: e64f1fe9756b Author: farvidsson Date: 2013-10-24 10:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e64f1fe9756b 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes. Reviewed-by: coleenp, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp Changeset: d70a665e25d7 Author: iklam Date: 2013-10-24 22:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d70a665e25d7 8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9 Reviewed-by: dcubed, iveresov Contributed-by: gerard.ziemski at oracle.com ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: e4f478e7781b Author: jbachorik Date: 2013-10-25 09:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e4f478e7781b 8027294: Prepare hotspot for non TOD based uptime counter Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime. Reviewed-by: dholmes, sla ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: a6177f601c64 Author: hseigel Date: 2013-10-25 11:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a6177f601c64 8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space. Reviewed-by: stefank, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 634715d59d9e Author: hseigel Date: 2013-10-25 11:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/634715d59d9e Merge Changeset: 209aa13ab8c0 Author: coleenp Date: 2013-10-25 15:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/209aa13ab8c0 8024927: Nashorn performance regression with CompressedOops Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops Reviewed-by: stefank, hseigel, goetz ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CompressedOops/CompressedClassPointers.java Changeset: b4aa8fc5d0d5 Author: ccheung Date: 2013-10-25 22:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b4aa8fc5d0d5 Merge ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/memory/metaspace.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1a04de1aaedb Author: dsamersoff Date: 2013-10-28 21:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a04de1aaedb 8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot Summary: Fixed two compilation-breaking nits Reviewed-by: sla, dholmes ! agent/src/os/bsd/ps_proc.c Changeset: 85730a185147 Author: ccheung Date: 2013-10-30 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85730a185147 Merge From vladimir.danushevsky at oracle.com Wed Oct 30 18:50:32 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 31 Oct 2013 01:50:32 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131031015116.EA12762860@hg.openjdk.java.net> Changeset: 292050e5d5ea Author: dholmes Date: 2013-10-24 00:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/292050e5d5ea 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build Reviewed-by: coleenp, twisti ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/thread.cpp Changeset: 066778844ed9 Author: jprovino Date: 2013-10-27 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/066778844ed9 Merge Changeset: f2f9139ccde9 Author: jprovino Date: 2013-10-30 16:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f2f9139ccde9 Merge Changeset: a007575ea726 Author: vladidan Date: 2013-10-30 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a007575ea726 Merge From coleen.phillimore at oracle.com Wed Oct 30 19:54:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Oct 2013 22:54:02 -0400 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle Message-ID: <5271C64A.8010001@oracle.com> 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. This is two bug fixes to the same code. open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ bug link https://bugs.openjdk.java.net/browse/JDK-8026946 https://bugs.openjdk.java.net/browse/JDK-8026948 Tested with vm.quick.testlist - and verified the jdi tests eg nsk/jdi/BScenarios/hotswap/tc01x001 test this path. Thanks, Coleen From coleen.phillimore at oracle.com Wed Oct 30 20:08:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Oct 2013 23:08:40 -0400 Subject: RFR (xs) 8027616: Off by one error in putback for compressed oops nashorn performance impr,ovement Message-ID: <5271C9B8.4030709@oracle.com> Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other. open webrev at http://cr.openjdk.java.net/~coleenp/8027616/ bug link https://bugs.openjdk.java.net/browse/JDK-8027616 Tested with jtreg tests for metaspace and compressed class pointers. Thanks, Coleen From stefan.karlsson at oracle.com Wed Oct 30 23:00:25 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 31 Oct 2013 07:00:25 +0100 Subject: RFR (xs) 8027616: Off by one error in putback for compressed oops nashorn performance impr,ovement In-Reply-To: <5271C9B8.4030709@oracle.com> References: <5271C9B8.4030709@oracle.com> Message-ID: <5271F1F9.2070108@oracle.com> On 2013-10-31 04:08, Coleen Phillimore wrote: > Summary: Should compare bounds greater than or equal 4G when deciding > if shift is > needed or CDS area + compressed class space are within 4G of each other. > > open webrev at http://cr.openjdk.java.net/~coleenp/8027616/ Looks good. StefanK > bug link https://bugs.openjdk.java.net/browse/JDK-8027616 > > Tested with jtreg tests for metaspace and compressed class pointers. > > Thanks, > Coleen From volker.simonis at gmail.com Thu Oct 31 01:36:26 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Oct 2013 09:36:26 +0100 Subject: CFV: New Project: JDK 9 In-Reply-To: <20131030153020.274677@eggemoggin.niobe.net> References: <20131030153020.274677@eggemoggin.niobe.net> Message-ID: Hi Mark, what's the reasoning behind "The Project's repositories will initially be open for bug fixes and small enhancements only.". Is this a change of the development model compared to JDK 8 - i.e. will 'bigger changes' (whatever that may be) be only allowed if theres' a JEP for them? And how does the creation of the JDK 9 project affect the HotSpot development. I recall from various discussions that you wanted to abandon the HotSpot Express model. So will the JDK 9 still use the latest and greatest HotSpot from hsx/hotspot-main or do you plan to have another model? I you still use the one from hsx/hotspot-main, will the HotSpot version number be bumped to 26 once the JDK 9 repositories have been created. Thank you and best regards, Volker On Wed, Oct 30, 2013 at 11:30 PM, wrote: > I hereby propose the creation of the JDK 9 Project, with me as the Lead > and the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce an open-source reference > implementation of the Java SE 9 Platform, which will be specified in a > corresponding JSR, yet to be submitted, in the Java Community Process. > > The Project's repositories will initially be open for bug fixes and > small enhancements only. Features for the release will be proposed > and tracked via the existing JEP Process [1]. > > Anyone who holds the Author, Committer, or Reviewer role in the JDK 8 > Project [2] and has contributed at least one changeset to JDK 8 will > be granted the same role in the JDK 9 Project. > > Votes are due by 23:59 UTC on Wednesday, 13 November [3]. > > Only current OpenJDK Members [4] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > - Mark > > > [1] http://openjdk.java.net/jeps > [2] http://openjdk.java.net/census#jdk8 > [3] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+9+CFV&iso=20131113T2359 > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From harold.seigel at oracle.com Thu Oct 31 05:52:41 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 31 Oct 2013 08:52:41 -0400 Subject: RFR (xs) 8027616: Off by one error in putback for compressed oops nashorn performance impr,ovement In-Reply-To: <5271F1F9.2070108@oracle.com> References: <5271C9B8.4030709@oracle.com> <5271F1F9.2070108@oracle.com> Message-ID: <52725299.2030002@oracle.com> Looks good to me, also. Thanks, Harold On 10/31/2013 2:00 AM, Stefan Karlsson wrote: > On 2013-10-31 04:08, Coleen Phillimore wrote: >> Summary: Should compare bounds greater than or equal 4G when deciding >> if shift is >> needed or CDS area + compressed class space are within 4G of each >> other. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8027616/ > > Looks good. > > StefanK > >> bug link https://bugs.openjdk.java.net/browse/JDK-8027616 >> >> Tested with jtreg tests for metaspace and compressed class pointers. >> >> Thanks, >> Coleen > From zhengyu.gu at oracle.com Thu Oct 31 06:11:48 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 31 Oct 2013 09:11:48 -0400 Subject: RFR (xs) 8027616: Off by one error in putback for compressed oops nashorn performance impr,ovement In-Reply-To: <5271C9B8.4030709@oracle.com> References: <5271C9B8.4030709@oracle.com> Message-ID: <52725714.1090106@oracle.com> Good to me. -Zhengyu On 10/30/2013 11:08 PM, Coleen Phillimore wrote: > Summary: Should compare bounds greater than or equal 4G when deciding > if shift is > needed or CDS area + compressed class space are within 4G of each other. > > open webrev at http://cr.openjdk.java.net/~coleenp/8027616/ > bug link https://bugs.openjdk.java.net/browse/JDK-8027616 > > Tested with jtreg tests for metaspace and compressed class pointers. > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Oct 31 07:29:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 31 Oct 2013 10:29:34 -0400 Subject: RFR (xs) 8027616: Off by one error in putback for compressed oops nashorn performance impr,ovement In-Reply-To: <52725714.1090106@oracle.com> References: <5271C9B8.4030709@oracle.com> <52725714.1090106@oracle.com> Message-ID: <5272694E.6000307@oracle.com> Thank you Stefan, Harold and Zhengyu. Coleen On 10/31/2013 09:11 AM, Zhengyu Gu wrote: > Good to me. > > -Zhengyu > > On 10/30/2013 11:08 PM, Coleen Phillimore wrote: >> Summary: Should compare bounds greater than or equal 4G when deciding >> if shift is >> needed or CDS area + compressed class space are within 4G of each >> other. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8027616/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8027616 >> >> Tested with jtreg tests for metaspace and compressed class pointers. >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Thu Oct 31 09:43:30 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Oct 2013 09:43:30 -0700 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle In-Reply-To: <5271C64A.8010001@oracle.com> References: <5271C64A.8010001@oracle.com> Message-ID: <527288B2.2030407@oracle.com> Coleen, It looks good, thank you for fixing it! Thanks, Serguei On 10/30/13 7:54 PM, Coleen Phillimore wrote: > 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might > not work with anonymous classes > Summary: Walk methods in breakpoints for marking on stack so they > aren't deallocated by redefine classes. Use class_holder rather than > class_loader to keep GC from reclaiming class owning the method. > > This is two bug fixes to the same code. > > open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ > bug link https://bugs.openjdk.java.net/browse/JDK-8026946 > https://bugs.openjdk.java.net/browse/JDK-8026948 > > Tested with vm.quick.testlist - and verified the jdi tests eg > nsk/jdi/BScenarios/hotswap/tc01x001 test this path. > > Thanks, > Coleen From karen.kinnear at oracle.com Thu Oct 31 10:53:20 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 31 Oct 2013 13:53:20 -0400 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces Message-ID: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> Please review: webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ bug: http://bugs.openjdk.java.net/browse/JDK-8027229 Added support for default method inheritance logic for interfaces. Removed interface methods from interface vtables. Better cleanup of 8027304 as well. specific tests: 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest including: testSuperConflict (fixed to match specification) 2. vmtestbase defmeth including: SuperCallTest:testSuperConflict (fixed to match specification) 3. jtreg java.util, java.lang, jdk.lambda 4. jck lang, vm 5. nsk vm.quick, vm.mlvm 6. nashorn 7. invoke tests 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 9. intfbug 10. defmeth with -Xshare:on (for 0 length method array) thanks, Karen matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html From calvin.cheung at oracle.com Thu Oct 31 14:26:32 2013 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 31 Oct 2013 14:26:32 -0700 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> Message-ID: <5272CB08.7000905@oracle.com> Karen, With your fix and the changes in the testSuperConflict tests to expect ICCE, the tests are passing in all 3 modes (direct, reflect, and invoke). Calvin On 10/31/2013 10:53 AM, Karen Kinnear wrote: > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util, java.lang, jdk.lambda > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. nashorn > 7. invoke tests > 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 9. intfbug > 10. defmeth with -Xshare:on (for 0 length method array) > > thanks, > Karen > > matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html > From karen.kinnear at oracle.com Thu Oct 31 14:47:00 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 31 Oct 2013 17:47:00 -0400 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <5272CB08.7000905@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> <5272CB08.7000905@oracle.com> Message-ID: <67F858CA-7CE7-45C1-8100-E01E2008412B@oracle.com> Thank you very much Calvin. I could still use two code reviews folks. thanks, Karen On Oct 31, 2013, at 5:26 PM, Calvin Cheung wrote: > Karen, > > With your fix and the changes in the testSuperConflict tests to expect ICCE, the tests are passing in all 3 modes (direct, reflect, and invoke). > > Calvin > > On 10/31/2013 10:53 AM, Karen Kinnear wrote: >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util, java.lang, jdk.lambda >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. nashorn >> 7. invoke tests >> 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 9. intfbug >> 10. defmeth with -Xshare:on (for 0 length method array) >> >> thanks, >> Karen >> >> matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html >> > From christian.thalinger at oracle.com Thu Oct 31 14:57:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 Oct 2013 14:57:20 -0700 Subject: Review/Comment request (S) 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes In-Reply-To: <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> References: <1828254.FSQ7MTpyjg@mgerdin03> <8249A000-4607-4956-868B-F90EA4381CED@oracle.com> <141f0829e10.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Message-ID: <34F4E29D-ABB1-45AD-B76B-2D8A07D23026@oracle.com> Looks good. On Oct 25, 2013, at 9:46 AM, Mikael Gerdin wrote: > > > On 25 October 2013 18:25:47 Christian Thalinger wrote: >> Good catch. Is there a similar issue on SPARC? > > I looked through the other platforms, they all seem to do single-byte loads for the indices. > On SPARC I suppose it's because it can't do unaligned multibyte loads. > /Mikael > >> >> On Oct 25, 2013, at 8:55 AM, Mikael Gerdin wrote: >> >> > Hi all, >> > Initially I'd like to hear people's opinions on this issue. It appears to have surfaced after we've reduced the unnecessary alignment "cushions" for metaspace together with the fact that we are now always able to use the very last bit of a VirtualSpace (in Metaspace). >> > The issue is extremely difficult to reproduce, because it relies on the exact order and size of all metaspace allocations for a run to trigger this problem. >> > Description of the problem: >> > We recently had some mysterious crashes in the GC testing, and I narrowed them down to the following scenario: >> > Imagine that we have a VirtualSpace (for Metaspace) >> > [ | bb] >> > ConstMethod >> > And that the very last object allocated in such a space is a ConstMethod, and that it has its embedded bytecodes filling up to the very end. >> > Consider the case when the second last bytecode (the one before "Xreturn") is one with an embedded 2-byte index (a constant pool or local variable index) for example: >> > - (bcp) checkcast #6 0xc0 0x00 0x06 - (bcp+3) areturn 0xb0 - (bcp+4) UNMAPPED MEMORY >> > The template interpreter here uses a 4-byte load on intel to read the index embedded in the checkcast: >> > mov 0x1(%esi),%ebx >> > this will read the bytes [bcp+1,bcp+4] and cause a SEGV. >> > I looked through the code for places where we do similar loads of 2-byte indexes and found the same problem for iload_w: >> > 0xe73f7fbb: mov 0x2(%esi),%ebx >> > 0xe73f7fbe: bswap %ebx >> > 0xe73f7fc0: shr $0x10,%ebx >> > I looked through most places where we emit >> > __ movl >> > __ bswap >> > and changed the places I could find which were affected. >> > Suggested fix: >> > Replace movl with load_[un]signed_short in the places where we load 2-byte values from the byte code stream. >> > I've verified that load_unsigned_short (which boils down to movzwl, opcodes 0x0f 0xb7 only reads 2 bytes). >> > Buglink: https://bugs.openjdk.java.net/browse/JDK-8027252 >> > Webrev: http://cr.openjdk.java.net/~mgerdin/8027252/webrev.0/ >> > Testing: >> > vm.quick.testlist -Xint on linux-i586 and x86_64(running) >> > Thanks >> > /Mikael >> > > From erik.helin at oracle.com Thu Oct 31 15:02:21 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 31 Oct 2013 22:02:21 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20131031220225.74FC5628BD@hg.openjdk.java.net> Changeset: 3b3133d93fb6 Author: brutisso Date: 2013-10-28 13:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b3133d93fb6 8027132: Print deprecation warning message for the flags controlling the CMS foreground collector Reviewed-by: stefank, ehelin, ysr, tschatzl ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestCMSForegroundFlags.java Changeset: 6d965678f21e Author: ehelin Date: 2013-10-31 21:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d965678f21e Merge From John.Coomes at oracle.com Thu Oct 31 16:23:17 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 31 Oct 2013 16:23:17 -0700 Subject: hsx and jdk9 (was Re: CFV: New Project: JDK 9) In-Reply-To: References: <20131030153020.274677@eggemoggin.niobe.net> Message-ID: <21106.58981.754039.206219@oracle.com> Volker Simonis (volker.simonis at gmail.com) wrote: > Hi Mark, > ... > And how does the creation of the JDK 9 project affect the HotSpot > development. I recall from various discussions that you wanted to > abandon the HotSpot Express model. So will the JDK 9 still use the > latest and greatest HotSpot from hsx/hotspot-main or do you plan to > have another model? ... Hi Volker, Note that I've changed the subject and BCC'd discuss, since I think this is best handled on the hotspot-dev mailing list. We (hotspot) will at some point start integrating sources from hsx/hotspot-main into the jdk9 master repos; the process will be similar to what we have done during jdk8 development. In other words, hsx/hotspot-main (and the related hsx/hotspot-{group} repos) will remain our "ongoing-development" repos. Note that currently the repos are targeting jdk8, so *only* jdk8 fixes should be pushed to hsx/hotspot-main and friends. > ... I you still use the one from hsx/hotspot-main, > will the HotSpot version number be bumped to 26 once the JDK 9 > repositories have been created. We actually want to drop the separate version number for hotspot. There was some thought of doing that for jdk8, but it was rather late in the release. When the jdk9 repos open and hsx/hotspot-main switches to jdk9 development (or soon after), we want to change the sources so that 'java -version' simply reports the jdk version. Here's an example of what a promoted build of the Oracle JDK might look like: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) Java HotSpot(TM) Server VM (build 1.9.0-ea-b01, mixed mode) Builds by developers would most likely not have the build number set, so instead of a build number we would substitute something like a mercurial hash if available, or a timestamp if not. Here's one possible example (note that this has not finalized by any means): java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) Java HotSpot(TM) Server VM (build 1.9.0-ea-b01+d8eaf13402cd, mixed mode) Which means it's based on 1.9 b01, but has additional changesets beyond that, and the 'tip' changeset is d8eaf13402cd. -John > On Wed, Oct 30, 2013 at 11:30 PM, wrote: > > I hereby propose the creation of the JDK 9 Project, with me as the Lead > > and the Governing Board as the sponsoring Group. > > > > The goal of this Project will be to produce an open-source reference > > implementation of the Java SE 9 Platform, which will be specified in a > > corresponding JSR, yet to be submitted, in the Java Community Process. > > > > The Project's repositories will initially be open for bug fixes and > > small enhancements only. Features for the release will be proposed > > and tracked via the existing JEP Process [1]. > > > > Anyone who holds the Author, Committer, or Reviewer role in the JDK 8 > > Project [2] and has contributed at least one changeset to JDK 8 will > > be granted the same role in the JDK 9 Project. > > > > Votes are due by 23:59 UTC on Wednesday, 13 November [3]. > > > > Only current OpenJDK Members [4] are eligible to vote on this motion. > > Votes must be cast in the open on the discuss list. Replying to this > > message is sufficient if your mail program honors the Reply-To header. > > > > For Lazy Consensus voting instructions, see [5]. > > > > - Mark > > > > > > [1] http://openjdk.java.net/jeps > > [2] http://openjdk.java.net/census#jdk8 > > [3] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+9+CFV&iso=20131113T2359 > > [4] http://openjdk.java.net/census#members > > [5] http://openjdk.java.net/projects/#new-project-vote From igor.veresov at oracle.com Thu Oct 31 17:36:24 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 01 Nov 2013 00:36:24 +0000 Subject: hg: hsx/hotspot-main/hotspot: 15 new changesets Message-ID: <20131101003658.06790628C4@hg.openjdk.java.net> Changeset: bd3237e0e18d Author: twisti Date: 2013-10-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bd3237e0e18d 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: jrose, roland ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/handles.cpp Changeset: cbe8ba0fb8fc Author: twisti Date: 2013-10-24 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cbe8ba0fb8fc Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: f01788f13696 Author: adlertz Date: 2013-10-25 10:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f01788f13696 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal Reviewed-by: roland ! src/share/vm/opto/postaloc.cpp Changeset: 7ae254fd0b3c Author: adlertz Date: 2013-10-25 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ae254fd0b3c Merge Changeset: 6c2f07d1495f Author: roland Date: 2013-10-28 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c2f07d1495f 8027140: Assertion in compiler when running bigapps/Kitchensink/stability Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced Reviewed-by: twisti, iveresov ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: bfdb530cdffa Author: roland Date: 2013-10-28 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bfdb530cdffa Merge Changeset: a196f1aaec86 Author: anoll Date: 2013-10-25 22:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a196f1aaec86 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Summary: Exit compiler threads early during startup so that wrong error message is not printed Reviewed-by: iveresov, twisti ! src/share/vm/compiler/compileBroker.cpp + test/compiler/startup/StartupOutput.java Changeset: 8c16f426dbb2 Author: iveresov Date: 2013-10-28 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c16f426dbb2 Merge Changeset: fc1632f5021a Author: iveresov Date: 2013-10-28 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fc1632f5021a Merge Changeset: a57a165b8296 Author: rbackman Date: 2013-10-28 08:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a57a165b8296 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Reviewed-by: kvn, roland ! src/share/vm/opto/library_call.cpp ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Changeset: 60a32bb8ff99 Author: rbackman Date: 2013-10-30 13:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/60a32bb8ff99 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Reviewed-by: duke ! src/share/vm/opto/loopTransform.cpp + test/compiler/intrinsics/mathexact/NestedMathExactTest.java Changeset: 4d3575d37a07 Author: iveresov Date: 2013-10-30 22:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4d3575d37a07 8026735: Stream tests throw java.lang.IncompatibleClassChangeError Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1 Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp + test/compiler/inlining/InlineDefaultMethod.java Changeset: 946a8294ab15 Author: iveresov Date: 2013-10-31 04:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/946a8294ab15 8024919: G1: SPECjbb2013 crashes due to a broken object reference Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 2dcd0bd2920d Author: iveresov Date: 2013-10-31 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2dcd0bd2920d Merge Changeset: 0836a3c28c6a Author: iveresov Date: 2013-10-31 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0836a3c28c6a Merge