From aaron.grunthal at infinite-source.de Tue Jan 1 03:57:44 2013 From: aaron.grunthal at infinite-source.de (Aaron Grunthal) Date: Tue, 01 Jan 2013 12:57:44 +0100 Subject: Unsafe.getObject() doesn't get loop hoisted in C2 Message-ID: <50E2CF38.9070604@infinite-source.de> While trying to optimize the JRuby runtime I've run into a field that's declared volatile but would benefit from non-volatile accesses for some important read operations. I've tried to use Unsafe.getObject to achieve identical semantics to a non-volatile field access, but it seems like hotspot C2 cannot perform loop invariant code motion on getObject. I.e. it's losing one of the major performance benefits of non-volatile accesses since the volatile read itself is not that expensive, at least on x86. My alternative is to declare the field as non-volatile and use Unsafe for volatile/atomic access in all other places, but this is something I would like to avoid as it seems more brittle than using getObject only in a few places (like CHM does for example). The question is whether this is intentional or something that should be fixed? - Aaron test + disassembly : https://gist.github.com/4420897#file-test-java compilable test: https://gist.github.com/4426366 Originally reported in concurrency-interest: http://cs.oswego.edu/pipermail/concurrency-interest/2013-January/010520.html From goetz.lindenmaier at sap.com Wed Jan 2 01:36:37 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Jan 2013 10:36:37 +0100 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <50D3CAA9.2080104@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> Hi David, I've also been on Xmas leave, but now I'm back. Thanks for pointing to the other RFEs. I agree the best solution is an algorithm with the least amount of memory ordering. But the current algorithm is wrong, and our solution is at least correct with no expected performance effect on your platforms. I also would appreciate a third opinion on this topic. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 21. Dezember 2012 03:34 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; Simonis, Volker Subject: Re: RFR(M): Memory ordering in taskqueue.hpp Hi Goetz, My apologies as I don't have a lot of time to go into this at the moment (and will shortly be starting Xmas leave). My preference is to see the necessary OrderAccess operations in the places they are needed. That is for two reasons: a) clarity in the algorithm b) performance (through not having redundant barriers [even if they become no-ops on a given platform]). When the barriers are hidden in individual accessors no-one can tell where they are actually needed, and if things don't work the only available response is to "crank up" the kind of barrier used. I'd prefer to see the ordering dependencies clearly defined in the code. eg at least: > void set_empty() { > _bottom = 0; > OrderAccess::release_store_ptr((volatile intptr_t*)&_age, 0); > } (with suitable comments) I'm not saying the hotspot code necessarily already does this. It is a sad fact that TSO assumptions have leached through into a lot of the hotspot code and caused bugs on non-TSO platforms. This certainly needs to be fixed. But again my preference is to see ordering dependencies explicitly called out and addressed. That all said I am not the ultimate arbiter here. This is GC code and it belongs to the GC folk (who are being conspicuously silent ;-) ). If they are prepared to take it as-is then I'm not standing in the way. With regards to problems with OrderAccess please see: http://bugs.sun.com/view_bug.do?bug_id=7143664 7143664 : Clean up OrderAccess implementations and usage Thanks, David ----- On 21/12/2012 6:23 AM, Lindenmaier, Goetz wrote: > Hi David, > > I understand that you want selected corrections, not the > solution we chose that does it everywhere. > > But do you agree that our solution does not introduce any > overhead on x86 and sparc? > > > > I'll try to explain why I think this is the case using the > example you brought up: > > void set_empty() { > _bottom = 0; > _age.set(0); > } > > will result in something like > > x86_64 our ppc our ia64 > ------ ------- -------- > movl 0, _bottom swz st4.rel > movq 0, _age sd st8.rel > > which is correct on x86 and ia64, but wrong on power. > > void set_empty() { > _bottom = 0; > OrderAccess::storestore(); > _age.set(0); > } > > will result in something like > > x86_64 our ppc our ia64 > ------ ------- -------- > movl 0, _bottom swz st4.rel > movl 0, local_dummy lwsync mf > movq 0, _age sd st8.rel > > which is correct, but inefficient on x86_64 (a bit) and ia64. > > while > > void set_empty() { > _bottom = 0; > OrderAccess::release_store_ptr((volatile intptr_t*)&_age, 0); > } > > will result in > > movl 0, _bottom swz st4.rel > movq 0, _age lwsync; sd st8.rel > > which is correct and efficient. > > > > By the way, if you have a PPC port, do you have a machine to build > and run the openJDK PPC port? > >> (modulo OrderAccess is far from perfect and has some outstanding issues). > What are the problems of the OrderAccess implementation? > > Best regards, > Goetz. > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Thursday, December 20, 2012 2:36 AM > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> first, thanks for the fast replies. Sorry it took me a day now! > > No problem. I can't guarantee response times either :) > >>> I didn't say that. I said these two need to be ordered and asked which >>> other paired accesses to these variables need to be ordered. >> Together with a colleague I looked at the code. To us it seems >> very hard to identify places where access ordering is not needed. >> Especially we think there will be places in the users of the >> task queue that would need barriers to ensure ordering. >> But we think, the algorithm should be self-contained, doing all the >> required ordering itself. > > I agree the algorithm should be self-contained. My point is that in > other places where we implement lock-free algorithm was put in the > barriers/fences in the algorithmic code in the places needed we don't > automatically wrap all of the variables accesses with code that > introduces pre/post barriers (of whatever form). > >> Further, a barrier will spoil performance on x86 etc, because there it >> issues a lock instruction, which is not needed. > > You issue the appropriate barrier/fence for the situation and they > should be implemented in whatever form needed for the given platform > (modulo OrderAccess is far from perfect and has some outstanding issues). > >>> I said that what you were doing was effectively treating the C++ variables >>> as if they were Java volatile variables. That's not the way we handle >>> these issues in the VM we tend to place fences/barriers at the places in >>> lock-free algorithms that need them, rather than wrap the variables in >>> accessors that impose fences/barriers that are not always needed. >> >> As we understand, the C compilers on x86, sparc etc, enforce far more >> than required to implement C++ volatile, basically treating the fields >> like Java volatiles. Therefore your code is fine on your platforms. > > I think you are confusing things. The existing C/C++ compilers do very > little in regard to "volatile". It is only the latest multi-threading > variant of the C++ standard that even addresses this! Our C/C++ > compilers never issue any kind of memory barriers in response to a > load/store of a volatile variable. > >> The C++ compilers on PPC optimize far more, maxing out >> what the standard allows and the processer supports, leading to >> immediate errors, but also to very subtle ones. >> >> Our change makes explicit what the C compilers (except for PPC) do >> anyways, and what is required by the algorithm. (Maybe one could now >> even omit the volatile keywords - but we dare not try.) Thus, we get >> it right without any overhead on your platforms. > > This is getting things confused. The lock-free algorithms should be > written for the most lenient of memory-models and make no assumptions > about ordering. They should use the appropriate OrderAccess method where > needed for algorithmic correctness. > > You proposal wraps the C variable in accessors that use OrderAccess > operations on every access - in a similar way to how we have to handle > Java volatile accesses. And as I have said that is not the style we use > in hotspot's lock-free code. This has nothing to do with our compiler > versus your compiler (though if you have one that issues memory-barriers > directly then you'll get too much overhead.) > >>> Though we have not run into this particular issue. Did >>> it arise in the context of a particular GC? >> Issues are only on PPC, at least in parallelScavenge. I reproduced >> some of the immediate errors, but I don't think this really helps with >> the discussion. I will try G1 soon. Tell me if you want to know >> more, then I'll try to come up with a wrap-up of our past fixes. > > We have a PPC product and as I said we have not encountered this > problem, but we also run with limited GCs so may not have been > exercising this code. > > Thanks, > David > >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 18. Dezember 2012 12:19 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >> >> Hi Goetz, >> >> On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> why do you think only these two accesses have to be ordered? >> >> I didn't say that. I said these two need to be ordered and asked which >> other paired accesses to these variables need to be ordered. >> >>> As I understand, any two accesses in one thread to these fields have to be >>> orderered and must be written to memory to become visible in the proper order >>> to other threads. >> >> That depends on how they are used. It is the overall lock-free algorithm >> that is important here. There may be places where the order of access >> does not matter (and there may not be). >> >>> The PPC compiler really takes all advantages given by the >>> C-Standard to optimize this, and the processor reorders heavily. >> >> Yes I understand. Though we have not run into this particular issue. Did >> it arise in the context of a particular GC? >> >>> The specification of volatile in >>> Age get() const volatile { return _data; } >>> says that it must be read from memory, not that it can not be reordered. >> >> I didn't say anything about C/C++ volatile (which doesn't even say it >> must be read from memory - except perhaps in latest MT C++ standard?). I >> said that what you were doing was effectively treating the C++ variables >> as if they were Java volatile variables. That's not the way we handle >> these issues in the VM we tend to place fences/barriers at the places in >> lock-free algorithms that need them, rather than wrap the variables in >> accessors that impose fences/barriers that are not always needed. >> >> Cheers, >> David >> >>> Also, doing >>> OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top)) >>> is better wrt. to optimizations by C-compilers, as there first >>> is the whole address computation, and then the cast to volatile. >>> If we use >>> _age.top() >>> with >>> idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); } >>> compilers don't optimize that well. (We saw this on hpia64.) >>> Further, the access to, e.g., old_age.top() in pop_local_slow() would do >>> the OrderAccess, which is useless overhead. >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 18. Dezember 2012 01:24 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >>> >>> Hi Goetz, >>> >>> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> Once more, with webrev: >>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >>> >>> I can see that this function needs a storestore barrier: >>> >>> 237 void set_empty() { >>> 238 _bottom = 0; >>> 239 _age.set(0); >>> 240 } >>> >>> to preserve ordering. Are there other functions to which we can >>> constrain the loadload and storestore barriers rather than using the >>> setters/getters the way you have defined? This is always about a pair >>> (sometimes groups) of accesses so I'd rather deal with the pairs than >>> treat each field as if it were a Java volatile. >>> >>> Thanks, >>> David Holmes >>> >>> >>>> Sorry for that. >>>> >>>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp. >>>> >>>> On Platfoms with weak memory ordering the taskqueue is not accessed >>>> properly, as the accesses to the fields _bottom and _age are not ordered >>>> correctly. Volatile is not sufficient to enforce this, because it depends on >>>> what the compiler assumes to be necessary for volatile variables. >>>> >>>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from >>>> OrderAccess to access the fields in _age as well as _bottom. Further the code must always >>>> use the getter/setter methods to access _bottom, _age or the subfields of _age. >>>> On the other hand we can relax constraints for accesses to locals oldAge and newAge. >>>> >>>> The OrderAccess routines do simple load/stores on x86_64. >>>> >>>> I want to discuss this change here and would like very much to see it taking >>>> it's way into OpenJDK to support ports on platforms with weak memory >>>> ordering, and, in particular, our PPC port. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> From dmytro_sheyko at hotmail.com Wed Jan 2 08:47:46 2013 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 2 Jan 2013 19:47:46 +0300 Subject: Crash in ~RuntimeStub::_complete_monitor_locking_Java Message-ID: Hi, We have experienced several crashes in our application. Particularly this happened 5 times last year. It seems not too many, but this is really troublesome. What is especially interesting it happened almost in the same place. Stack: [0x6d540000,0x6d590000], sp=0x6d58f2cc, free space=316k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x1f590b] V [jvm.dll+0x2c7354] V [jvm.dll+0x2c9899] V [jvm.dll+0x2c9eac] V [jvm.dll+0x2ca0bb] V [jvm.dll+0x2a2b45] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::_complete_monitor_locking_Java J com.inforeach.util.xml.XMLData.getAttributeList()Ljava/util/List; J com.inforeach.util.xml.parser.XMLParser.parseDataWithChildren(Lcom/inforeach/util/xml/XMLData;)V j com.inforeach.util.xml.parser.XMLParser.parseData(Lcom/inforeach/util/xml/XMLData;)V+17 j com.inforeach.util.xml.XMLData.stringValue(IZI)Ljava/lang/String;+261 j com.inforeach.util.xml.XMLData.stringValue(IZ)Ljava/lang/String;+4 j com.inforeach.util.xml.XMLData.stringValue(ZZ)Ljava/lang/String;+11 j com.inforeach.util.xml.XMLData.stringValue(Z)Ljava/lang/String;+3 j com.inforeach.util.xml.XMLData.stringValue()Ljava/lang/String;+2 j com.inforeach.eventsrvc.rmi.ESRmiInwardEventBrokerManagerAdapter.getEventBrokerProperties(Ljava/lang/String;)Ljava/lang/String;+10 Could you suggest something to avoid such crashes? System info is following: OS: Windows Server 2003 family Build 3790 Service Pack 2 CPU:total 16 (8 cores per cpu, 2 threads per core) family 6 model 26 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, ht Memory: 4k page, physical 4194303k(4194303k free), swap 4194303k(4194303k free) vm_info: Java HotSpot(TM) Server VM (14.3-b01) for windows-x86 JRE (1.6.0_17-b04), built on Oct 11 2009 00:46:21 by "java_re" with MS VC++ 7.1 Full crash reports are attached. It's likely that the issue is already fixed in recent Java6 updates. If so, please let us know, which update we should use. Thanks, Dmytro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid4872.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130102/d2d98c93/hs_err_pid4872-0001.log -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6004.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130102/d2d98c93/hs_err_pid6004-0001.log -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6844.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130102/d2d98c93/hs_err_pid6844-0001.log -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid7264.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130102/d2d98c93/hs_err_pid7264-0001.log -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid9036.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130102/d2d98c93/hs_err_pid9036-0001.log From christian.thalinger at oracle.com Wed Jan 2 11:56:56 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Jan 2013 11:56:56 -0800 Subject: CFV: New HSX Reviewer: Stefan Karlsson In-Reply-To: <50D29225.7000009@oracle.com> References: <50D29225.7000009@oracle.com> Message-ID: <0C4EE8CF-1595-415F-8412-76023F9B4C41@oracle.com> Vote: yes On Dec 19, 2012, at 8:20 PM, Bengt Rutisson wrote: > > I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1]. > > Stefan is on his third year as a Committer on the HSX project. He is a key contributor in the Hotspot's GC group, working on all GCs. He has contributed 32 significant changesets as a Committer and is thus well-qualified to be a Reviewer on the HSX project. > > Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Bengt Rutisson > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From christian.thalinger at oracle.com Wed Jan 2 12:02:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Jan 2013 12:02:10 -0800 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: <50D5F8BF.1030000@LGonQn.Org> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> Message-ID: On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T O wrote: > Hi Alejandro, > Oops emails crossed in the net ... > See my latest email , I had to regenerate the webrev and patch - > This webrev s/b ok: > > Webrev: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ That looks good. -- Chris > > > Chris > > On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >> >> Hi Chris, >> In that case is not necessary. >> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >> but looks like it is against hsx/hsx24/hotspot. >> BTW, I went to check the webrev link and is unreachable, can you check >> that? >> Thanks >> Alejandro >> >> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>> Hi Alejandro, >>> >>> The only change since I tested this afternoon is the change >>> for the hotspot_version. I will re-run tests if you wish but it seems >>> unnecessary. >>> >>> Cheers! >>> Chris >>> >>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>> Hi >>>>> >>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>> sponsor >>>>> - Twisti ? } >>>>> >>>>> Attached is a backport (essentially resurrection of the Permgen code) >>>>> of 8000780 now updated with Roman Kennke's comments. Checked and built >>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>> >>>>> Please review. >>>>> >>>>> Cheers! >>>>> Chris >>>>> PS >>>>> Webrev is here: >>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ >>>>> >>>> Hi >>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>> Can you rework the patch/webrev against this repo: >>>> >>>> http://hg.openjdk.java.net/hsx/hsx24/hotspot >>>> >>>> once it's reviewed I can push it >>>> >>>> Thanks >>>> >> >> >> > From john.cuthbertson at oracle.com Wed Jan 2 12:05:28 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 02 Jan 2013 12:05:28 -0800 Subject: CFV: New HSX Reviewer: Stefan Karlsson In-Reply-To: <50D29225.7000009@oracle.com> References: <50D29225.7000009@oracle.com> Message-ID: <50E49308.1020907@oracle.com> Vote: yes JohnC On 12/19/2012 8:20 PM, Bengt Rutisson wrote: > > I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1]. > > Stefan is on his third year as a Committer on the HSX project. He is a > key contributor in the Hotspot's GC group, working on all GCs. He has > contributed 32 significant changesets as a Committer and is thus > well-qualified to be a Reviewer on the HSX project. > > Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week > voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Bengt Rutisson > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From roland.westrelin at oracle.com Thu Jan 3 01:54:05 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Jan 2013 10:54:05 +0100 Subject: RFR: 8004051: ARM: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow In-Reply-To: References: Message-ID: <578FBAD0-2754-4A50-A1A7-F7AC90F1AC36@oracle.com> > The proposed change increases limit of register based arguments to 20 across all platforms (the runtime memory space waste is small). > > http://cr.openjdk.java.net/~vladidan/8004051/webrev.00 It looks good. Roland. From vladimir.kozlov at oracle.com Thu Jan 3 08:42:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 08:42:39 -0800 Subject: RFR: 8004051: ARM: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow In-Reply-To: <578FBAD0-2754-4A50-A1A7-F7AC90F1AC36@oracle.com> References: <578FBAD0-2754-4A50-A1A7-F7AC90F1AC36@oracle.com> Message-ID: <50E5B4FF.1080004@oracle.com> Thank you for reviews, Roland Vladimir On 1/3/13 1:54 AM, Roland Westrelin wrote: >> The proposed change increases limit of register based arguments to 20 across all platforms (the runtime memory space waste is small). >> >> http://cr.openjdk.java.net/~vladidan/8004051/webrev.00 > > It looks good. > > Roland. > From Vladimir.Danushevsky at Oracle.com Thu Jan 3 09:57:35 2013 From: Vladimir.Danushevsky at Oracle.com (Vladimir Danushevsky) Date: Thu, 3 Jan 2013 12:57:35 -0500 Subject: RFR: 8005204: Provide more detailed output on CodeCache usage Message-ID: Code review for JDK-8005204 "Provide more detailed output on CodeCache usage" We are adding more detailed output on CodeCache usage. Corresponding command line options are: -XX:+PrintCodeCache - Will print the size of the codecache at VM exit. It will include the total size, used size, maximum used size, maximum free chunk, bounds, number of cached methods , etc. -XX:+PrintCodeCacheOnCompilation - Same as PrintCodeCache, but does so each time a method is compiled. This is useful if the app does not do a normal JVM exit. Sample output: CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb max_free_chunk=32226Kb bounds [0xb414a000, 0xb41d2000, 0xb614a000] total_blobs=131 nmethods=5 adapters=63 compilation: enabled Changeset: http://cr.openjdk.java.net/~vladidan/8005204/webrev.00/ Sponsoring Alexander Harlap for that submission From Vladimir.Danushevsky at Oracle.com Thu Jan 3 10:00:49 2013 From: Vladimir.Danushevsky at Oracle.com (Vladimir Danushevsky) Date: Thu, 3 Jan 2013 13:00:49 -0500 Subject: RFR: 8005639: Move InlineSynchronizedMethods flag from develop to product Message-ID: Code review for JDK-8005639 "Move InlineSynchronizedMethods flag from develop to product" According to research done, setting InlineSynchronizedMethods to false gave significant memory savings with performance difference below error of measurement. The InlineSynchronizedMethods flag should be moved from develop to product so users can take advantage of it if they want to try reducing codecache usage. Change is at http://cr.openjdk.java.net/~vladidan/8005639/webrev.00/ Sponsoring Alexander Harlap for that submission From vladimir.kozlov at oracle.com Thu Jan 3 10:25:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 10:25:01 -0800 Subject: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: References: Message-ID: <50E5CCFD.6020402@oracle.com> Looks good. One correction to request description: with -XX:+PrintCodeCacheOnCompilation VM prints only one line per compilation: CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb max_free_chunk=32226Kb Thanks, Vladimir On 1/3/13 9:57 AM, Vladimir Danushevsky wrote: > Code review for JDK-8005204 "Provide more detailed output on CodeCache > usage" > > We are adding more detailed output on CodeCache usage. > > Corresponding command line options are: > -XX:+PrintCodeCache - Will print the size of the codecache at VM > exit. It will include the total size, used size, maximum used size, > maximum free chunk, bounds, number of cached methods , etc. > -XX:+PrintCodeCacheOnCompilation - Same as PrintCodeCache, but does > so each time a method is compiled. This is useful if the app does not do > a normal JVM exit. > > Sample output: > > CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb > max_free_chunk=32226Kb > bounds [0xb414a000, 0xb41d2000, 0xb614a000] > total_blobs=131 nmethods=5 adapters=63 > compilation: enabled > > Changeset: http://cr.openjdk.java.net/~vladidan/8005204/webrev.00/ > > Sponsoring Alexander Harlap for that submission From vladimir.kozlov at oracle.com Thu Jan 3 10:25:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 10:25:45 -0800 Subject: RFR: 8005639: Move InlineSynchronizedMethods flag from develop to product In-Reply-To: References: Message-ID: <50E5CD29.7090905@oracle.com> Good. Vladimir On 1/3/13 10:00 AM, Vladimir Danushevsky wrote: > Code review for JDK-8005639 "Move InlineSynchronizedMethods flag from > develop to product" > > According to research done, setting InlineSynchronizedMethods to false > gave significant memory savings with performance difference below error > of measurement. The InlineSynchronizedMethods flag should be moved from > develop to product so users can take advantage of it if they want to try > reducing codecache usage. > > Change is at http://cr.openjdk.java.net/~vladidan/8005639/webrev.00/ > > Sponsoring Alexander Harlap for that submission From vitalyd at gmail.com Thu Jan 3 11:20:42 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 3 Jan 2013 14:20:42 -0500 Subject: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: References: Message-ID: Vladimir, Unrelated to your change, but does CompileBroker::handle_full_code_cache() need a ResourceMark since it calls stringStream::as_string()? Or is the RM created somewhere in the caller chain? Thanks Sent from my phone On Jan 3, 2013 12:59 PM, "Vladimir Danushevsky" < Vladimir.Danushevsky at oracle.com> wrote: > Code review for JDK-8005204 "Provide more detailed output on CodeCache > usage" > > We are adding more detailed output on CodeCache usage. > > Corresponding command line options are: > -XX:+PrintCodeCache - Will print the size of the codecache at VM > exit. It will include the total size, used size, maximum used size, maximum > free chunk, bounds, number of cached methods , etc. > -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, but does > so each time a method is compiled. This is useful if the app does not do a > normal JVM exit. > > Sample output: > > CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb > max_free_chunk=32226Kb > bounds [0xb414a000, 0xb41d2000, 0xb614a000] > total_blobs=131 nmethods=5 adapters=63 > compilation: enabled > > Changeset: http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/ > > Sponsoring Alexander Harlap for that submission > From vladimir.kozlov at oracle.com Thu Jan 3 12:16:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 12:16:57 -0800 Subject: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: References: Message-ID: <50E5E739.5040207@oracle.com> On 1/3/13 11:20 AM, Vitaly Davidovich wrote: > Vladimir, > > Unrelated to your change, but does CompileBroker::handle_full_code_cache() > need a ResourceMark since it calls stringStream::as_string()? Or is the RM > created somewhere in the caller chain? File separate bug. I found several places with similar usage of stringStream::as_string() without ResourceMark. What I missed in my review for this changes is that CompileBroker::handle_full_code_cache() does not obtain CodeCache_lock before calling CodeCache::print_summary(tty) which I think we need here. Also it should be placed at the end of method after compilation is switched off otherwise it will incorrectly print that compilation: enabled. Thanks, Vladimir > > Thanks > > Sent from my phone > On Jan 3, 2013 12:59 PM, "Vladimir Danushevsky" < > Vladimir.Danushevsky at oracle.com> wrote: > >> Code review for JDK-8005204 "Provide more detailed output on CodeCache >> usage" >> >> We are adding more detailed output on CodeCache usage. >> >> Corresponding command line options are: >> -XX:+PrintCodeCache - Will print the size of the codecache at VM >> exit. It will include the total size, used size, maximum used size, maximum >> free chunk, bounds, number of cached methods , etc. >> -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, but does >> so each time a method is compiled. This is useful if the app does not do a >> normal JVM exit. >> >> Sample output: >> >> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >> max_free_chunk=32226Kb >> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >> total_blobs=131 nmethods=5 adapters=63 >> compilation: enabled >> >> Changeset: http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/ >> >> Sponsoring Alexander Harlap for that submission >> From john.coomes at oracle.com Thu Jan 3 20:37:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:37:51 +0000 Subject: hg: hsx/hotspot-main: 5 new changesets Message-ID: <20130104043751.63F0147523@hg.openjdk.java.net> Changeset: 2ed5be3dd506 Author: lana Date: 2012-12-16 22:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2ed5be3dd506 Merge Changeset: a0779b1e9a4d Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a0779b1e9a4d 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: 68a81db3ceb1 Author: lana Date: 2012-12-18 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/68a81db3ceb1 Merge Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/51ad2a343420 Merge Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:37:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:37:55 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b71 for changeset 8171d23e914d Message-ID: <20130104043759.1696447524@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:38:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:38:04 +0000 Subject: hg: hsx/hotspot-main/jaxp: 6 new changesets Message-ID: <20130104043825.4490F47525@hg.openjdk.java.net> Changeset: b1fdb101c82e Author: joehw Date: 2012-12-14 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b1fdb101c82e 8003260: [findbug] some fields should be package protected Summary: change public or protected mutable static fields to private or package private. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 8a20e948b806 Author: lana Date: 2012-12-16 22:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/8a20e948b806 Merge Changeset: 15b32367b23c Author: joehw Date: 2012-12-18 21:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/15b32367b23c 8003261: static field is public but not final Summary: add final to fVersion field, and make it a non-compile time constant. Reviewed-by: hawtin, lancea, dholmes, chegar ! src/com/sun/org/apache/xerces/internal/impl/Version.java Changeset: d4aea0225e80 Author: joehw Date: 2012-12-27 18:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d4aea0225e80 8005473: Warnings compiling jaxp Summary: clean up compiling warnings. Reviewed-by: weijun, chegar, forax ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/499be952a291 Merge Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:38:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:38:29 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b71 for changeset f577a39c9fb3 Message-ID: <20130104043835.0D81147526@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:40:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:40:28 +0000 Subject: hg: hsx/hotspot-main/jdk: 53 new changesets Message-ID: <20130104045111.0036747527@hg.openjdk.java.net> Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf2bcb293f0b Merge Changeset: 69fd3f3d20c1 Author: alanb Date: 2012-12-15 15:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69fd3f3d20c1 8004963: URLConnection, downgrade normative reference to ${java.home}/lib/content-types.properties Reviewed-by: chegar ! src/share/classes/java/net/URLConnection.java Changeset: eaaec81aa974 Author: weijun Date: 2012-12-17 12:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eaaec81aa974 7197159: accept different kvno if there no match Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptionKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java + test/sun/security/krb5/auto/KvnoNA.java ! test/sun/security/krb5/auto/MoreKvno.java Changeset: f959e0cc8766 Author: lana Date: 2012-12-16 22:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f959e0cc8766 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: a02212de8db6 Author: uta Date: 2012-12-17 14:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a02212de8db6 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem Summary: the tests were refactored to drop AWT dependence where it was possible. Reviewed-by: alanb, mchung ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/logging/LoggingDeadlock4.java ! test/sun/tools/jrunscript/common.sh Changeset: e4d88a7352c6 Author: mullan Date: 2012-12-17 08:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e4d88a7352c6 8004234: Downgrade normative references to ${java.home}/lib/security/krb5.conf Reviewed-by: alanb, weijun ! src/share/classes/javax/security/auth/kerberos/package.html Changeset: 4a21f818ebb1 Author: mullan Date: 2012-12-17 08:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4a21f818ebb1 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: bcf79e6f52a0 Author: chegar Date: 2012-12-17 16:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bcf79e6f52a0 8005081: java/util/prefs/PrefsSpi.sh fails on macos-x Reviewed-by: alanb ! test/java/util/prefs/PrefsSpi.sh Changeset: 9f1b516cd9cb Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f1b516cd9cb 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! make/docs/NON_CORE_PKGS.gmk Changeset: bac477d67867 Author: jjg Date: 2012-12-17 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bac477d67867 8004832: Add new doclint package Reviewed-by: erikj, ohair ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! makefiles/CreateJars.gmk Changeset: 0fabdf676395 Author: martin Date: 2012-12-17 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0fabdf676395 8004863: Infinite Loop in KeepAliveStream Reviewed-by: chegar ! src/share/classes/sun/net/www/http/KeepAliveStream.java + test/sun/net/www/http/KeepAliveStream/InfiniteLoop.java Changeset: 0a1398021c7c Author: darcy Date: 2012-12-18 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a1398021c7c 8005042: Add Method.isDefault to core reflection Reviewed-by: alanb, forax, mduigou, jgish, mchung ! src/share/classes/java/lang/reflect/Method.java + test/java/lang/reflect/Method/IsDefaultTest.java Changeset: 6d977f61af5e Author: darcy Date: 2012-12-18 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d977f61af5e 8004699: Add type annotation storage to Constructor, Field and Method Reviewed-by: darcy, dholmes Contributed-by: joel.franck at oracle.com ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java Changeset: e515956879cd Author: lana Date: 2012-12-18 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e515956879cd Merge Changeset: c79b26b8efe0 Author: sjiang Date: 2012-12-19 11:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c79b26b8efe0 7158614: JMXStartStopTest.sh failing intermittently Summary: fixed 3 problems here: 1) checked the lock file too eary 2) never got the process id of a java test 3) some shell commands were not supported in some Solaris machines. Reviewed-by: dsamersoff, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 3fd3bcc8bd42 Author: joehw Date: 2012-12-19 12:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3fd3bcc8bd42 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present Reviewed-by: alanb, mchung, psandoz + src/share/classes/jdk/internal/org/xml/sax/Attributes.java + src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java + src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java + src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java + src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java + src/share/classes/jdk/internal/org/xml/sax/InputSource.java + src/share/classes/jdk/internal/org/xml/sax/Locator.java + src/share/classes/jdk/internal/org/xml/sax/SAXException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java + src/share/classes/jdk/internal/org/xml/sax/XMLReader.java + src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java + src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java + src/share/classes/jdk/internal/util/xml/SAXParser.java + src/share/classes/jdk/internal/util/xml/XMLStreamException.java + src/share/classes/jdk/internal/util/xml/XMLStreamWriter.java + src/share/classes/jdk/internal/util/xml/impl/Attrs.java + src/share/classes/jdk/internal/util/xml/impl/Input.java + src/share/classes/jdk/internal/util/xml/impl/Pair.java + src/share/classes/jdk/internal/util/xml/impl/Parser.java + src/share/classes/jdk/internal/util/xml/impl/ParserSAX.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF16.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF8.java + src/share/classes/jdk/internal/util/xml/impl/SAXParserImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLWriter.java Changeset: cf15abdcdf88 Author: alanb Date: 2012-12-19 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf15abdcdf88 8005248: (props) Integrate small footprint parser into Properties Reviewed-by: joehw, mchung, psandoz, erikj ! make/jdk/Makefile - make/jdk/asm/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadCase.xml + test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/NoClosingTag.xml + test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoRoot.xml + test/java/util/Properties/invalidxml/NotQuoted.xml + test/java/util/Properties/invalidxml/README.txt Changeset: 1f9c19741285 Author: darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/Method.java Changeset: b600d490dc57 Author: dsamersoff Date: 2012-12-20 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b600d490dc57 6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject Summary: call readObject in all cases Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java Changeset: e43f90d5af11 Author: dsamersoff Date: 2012-12-20 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e43f90d5af11 6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure Summary: the catch block in the fetchNotifs() method is extended to expect UnmarshalException Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java Changeset: 3f014bc09297 Author: dsamersoff Date: 2012-12-20 17:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f014bc09297 7009998: JMX synchronization during connection restart is faulty Summary: add a return statement after the re-connecting has finished and the state is CONNECTED Reviewed-by: sjiang Contributed-by: jaroslav.bachorik at oracle.com ! make/netbeans/jmx/build.properties ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: d01a810798e0 Author: dl Date: 2012-12-20 13:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d01a810798e0 8002356: Add ForkJoin common pool and CountedCompleter Reviewed-by: chegar, mduigou ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: 31d2f9995d6c Author: chegar Date: 2012-12-20 15:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31d2f9995d6c 8005306: Redundant cast warning in KeepAliveStream.java Reviewed-by: alanb ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: c1a55ee9618e Author: dsamersoff Date: 2012-12-20 20:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1a55ee9618e 8005309: Missed tests for 6783290,6937053,7009998 Summary: Missed tests for 6783290,6937053,7009998 Reviewed-by: sjiang, emcmanus Contributed-by: jaroslav.bachorik at oracle.com + test/com/sun/jmx/remote/CCAdminReconnectTest.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh + test/javax/management/MBeanInfo/SerializationTest1.java Changeset: edb71a37fcb7 Author: alanb Date: 2012-12-20 20:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/edb71a37fcb7 8001048: JSR-160: Allow IIOP transport to be optional Reviewed-by: dsamersoff, dfuchs, mchung ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/package.html ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java Changeset: eeda18683ddc Author: alanb Date: 2012-12-20 20:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eeda18683ddc 8005281: (props) loadFromXML/storeToXML with small parser is not thread safe Reviewed-by: mchung ! src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java + test/java/util/Properties/ConcurrentLoadAndStoreXML.java Changeset: 60adb69bf043 Author: smarks Date: 2012-12-20 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60adb69bf043 8005290: remove -showversion from RMI test library subprocess mechanism Reviewed-by: jgish, chegar, dmocek ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: 42ee6b6ad373 Author: jbachorik Date: 2012-12-21 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42ee6b6ad373 7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently Summary: ClientCommunicatorAdmin should call gotIOException((IOException)e) instead of restart((IOException)e) when detecting a communication error, because the method gotIOException will send a failure notification if necessary. Reviewed-by: emcmanus, sjiang Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: 86c10d1484e9 Author: sjiang Date: 2012-12-21 10:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86c10d1484e9 8005325: The script should use TESTVMOPTS Summary: Put back TESTVMOPTS which was removed by mistake. Reviewed-by: smarks ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: c1227b872a12 Author: joehw Date: 2012-12-21 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1227b872a12 8005280: (props) Improve test coverage for small XML parser Summary: added a few more invalid XML files, international characters to LoadAndStore test, and a behavior compatibility test. Reviewed-by: alanb, lancea + test/java/util/Properties/Compatibility.xml + test/java/util/Properties/CompatibilityTest.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadDocType.xml - test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/DTDRootNotMatch.xml + test/java/util/Properties/invalidxml/IllegalComment.xml + test/java/util/Properties/invalidxml/IllegalEntry.xml + test/java/util/Properties/invalidxml/IllegalEntry1.xml + test/java/util/Properties/invalidxml/IllegalKeyAttribute.xml + test/java/util/Properties/invalidxml/NoDocType.xml - test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoNamespaceSupport.xml Changeset: 4d28776d7007 Author: mullan Date: 2012-12-26 10:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d28776d7007 8005117: Eliminate dependency from ConfigSpiFile to com.sun.security.auth.login.ConfigFile Reviewed-by: alanb, mchung, weijun ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java Changeset: d9cab18f326a Author: mullan Date: 2012-12-26 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d9cab18f326a Merge - make/jdk/asm/Makefile Changeset: 9d984ccd17fc Author: chegar Date: 2012-12-27 21:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d984ccd17fc 8003981: Support Parallel Array Sorting - JEP 103 Reviewed-by: chegar, forax, dholmes, dl Contributed-by: david.holmes at oracle.com, dl at cs.oswego.edu, chris.hegarty at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java + src/share/classes/java/util/ArraysParallelSortHelpers.java + test/java/util/Arrays/ParallelSorting.java Changeset: 4ad38db38fff Author: okutsu Date: 2012-12-28 14:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4ad38db38fff 8005471: DateFormat: Time zone info is not localized when adapter is CLDR Reviewed-by: peytoia ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/TimeZone/CLDRDisplayNamesTest.java Changeset: 1da019e7999a Author: peytoia Date: 2012-12-28 15:07 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1da019e7999a 8005277: Regression in JDK 7 in Bidi implementation Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java ! test/java/text/Bidi/BidiConformance.java + test/java/text/Bidi/Bug8005277.java Changeset: f3ac419e2bf0 Author: okutsu Date: 2012-12-28 16:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3ac419e2bf0 8005561: typo in Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: 645d774b683a Author: xuelei Date: 2012-12-28 00:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/645d774b683a 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Summary: This restriction is applied via the Java Security property, "jdk.certpath.disabledAlgorithms". This will impact providers that adhere to this security property. Reviewed-by: mullan ! 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/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java + test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 4472a641b4dc Author: xuelei Date: 2012-12-28 03:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4472a641b4dc 8003265: Need to clone array of input/output parameters Reviewed-by: mullan ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: 46675076f753 Author: sjiang Date: 2012-12-28 16:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/46675076f753 7120365: DiffHBTest.java fails due to ConcurrentModificationException Summary: The problem is from the server notification forwarder, it should use a copy of listener set to do iterate. Reviewed-by: alanb ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! test/ProblemList.txt + test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java Changeset: 0cfcba56cfa7 Author: jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author: smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac5e29b62288 Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:53:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:53:56 +0000 Subject: hg: hsx/hotspot-main/langtools: 20 new changesets Message-ID: <20130104045450.D855047528@hg.openjdk.java.net> Changeset: 37a5d7eccb87 Author: vromero Date: 2012-12-14 11:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/37a5d7eccb87 8004976: test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java can fail Reviewed-by: jjg, mcimadamore ! test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java Changeset: de1ec6fc93fe Author: vromero Date: 2012-12-15 13:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/de1ec6fc93fe 8000518: Javac generates duplicate name_and_type constant pool entry for class BinaryOpValueExp.java Reviewed-by: jjg, mcimadamore ! 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/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.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/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + test/tools/javac/8000518/DuplicateConstantPoolEntry.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: f72dc656a306 Author: lana Date: 2012-12-16 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f72dc656a306 Merge Changeset: 02a18f209ab3 Author: vromero Date: 2012-12-17 14:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/02a18f209ab3 8004814: javadoc should be able to detect default methods Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/javadoc/MethodDoc.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java Changeset: 75ab654b5cd5 Author: jjg Date: 2012-12-17 07:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/75ab654b5cd5 8004832: Add new doclint package Reviewed-by: mcimadamore ! make/build.properties ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/TreePath.java + src/share/classes/com/sun/tools/doclint/Checker.java + src/share/classes/com/sun/tools/doclint/DocLint.java + src/share/classes/com/sun/tools/doclint/Entity.java + src/share/classes/com/sun/tools/doclint/Env.java + src/share/classes/com/sun/tools/doclint/HtmlTag.java + src/share/classes/com/sun/tools/doclint/Messages.java + src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocPretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/doclint/AccessTest.java + test/tools/doclint/AccessTest.package.out + test/tools/doclint/AccessTest.private.out + test/tools/doclint/AccessTest.protected.out + test/tools/doclint/AccessTest.public.out + test/tools/doclint/AccessibilityTest.java + test/tools/doclint/AccessibilityTest.out + test/tools/doclint/DocLintTester.java + test/tools/doclint/EmptyAuthorTest.java + test/tools/doclint/EmptyAuthorTest.out + test/tools/doclint/EmptyExceptionTest.java + test/tools/doclint/EmptyExceptionTest.out + test/tools/doclint/EmptyParamTest.java + test/tools/doclint/EmptyParamTest.out + test/tools/doclint/EmptyReturnTest.java + test/tools/doclint/EmptyReturnTest.out + test/tools/doclint/EmptySerialDataTest.java + test/tools/doclint/EmptySerialDataTest.out + test/tools/doclint/EmptySerialFieldTest.java + test/tools/doclint/EmptySerialFieldTest.out + test/tools/doclint/EmptySinceTest.java + test/tools/doclint/EmptySinceTest.out + test/tools/doclint/EmptyVersionTest.java + test/tools/doclint/EmptyVersionTest.out + test/tools/doclint/HtmlAttrsTest.java + test/tools/doclint/HtmlAttrsTest.out + test/tools/doclint/HtmlTagsTest.java + test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/MissingCommentTest.java + test/tools/doclint/MissingCommentTest.out + test/tools/doclint/MissingParamsTest.java + test/tools/doclint/MissingParamsTest.out + test/tools/doclint/MissingReturnTest.java + test/tools/doclint/MissingReturnTest.out + test/tools/doclint/MissingThrowsTest.java + test/tools/doclint/MissingThrowsTest.out + test/tools/doclint/OptionTest.java + test/tools/doclint/OverridesTest.java + test/tools/doclint/ReferenceTest.java + test/tools/doclint/ReferenceTest.out + test/tools/doclint/RunTest.java + test/tools/doclint/SyntaxTest.java + test/tools/doclint/SyntaxTest.out + test/tools/doclint/SyntheticTest.java + test/tools/doclint/ValidTest.java + test/tools/doclint/tidy/AnchorAlreadyDefined.java + test/tools/doclint/tidy/AnchorAlreadyDefined.out + test/tools/doclint/tidy/BadEnd.java + test/tools/doclint/tidy/BadEnd.out + test/tools/doclint/tidy/InsertImplicit.java + test/tools/doclint/tidy/InsertImplicit.out + test/tools/doclint/tidy/InvalidEntity.java + test/tools/doclint/tidy/InvalidEntity.out + test/tools/doclint/tidy/InvalidName.java + test/tools/doclint/tidy/InvalidName.out + test/tools/doclint/tidy/InvalidTag.java + test/tools/doclint/tidy/InvalidTag.out + test/tools/doclint/tidy/InvalidURI.java + test/tools/doclint/tidy/InvalidURI.out + test/tools/doclint/tidy/MissingGT.java + test/tools/doclint/tidy/MissingGT.out + test/tools/doclint/tidy/MissingTag.java + test/tools/doclint/tidy/MissingTag.out + test/tools/doclint/tidy/NestedTag.java + test/tools/doclint/tidy/NestedTag.out + test/tools/doclint/tidy/ParaInPre.java + test/tools/doclint/tidy/ParaInPre.out + test/tools/doclint/tidy/README.txt + test/tools/doclint/tidy/RepeatedAttr.java + test/tools/doclint/tidy/RepeatedAttr.out + test/tools/doclint/tidy/TextNotAllowed.java + test/tools/doclint/tidy/TextNotAllowed.out + test/tools/doclint/tidy/TrimmingEmptyTag.java + test/tools/doclint/tidy/TrimmingEmptyTag.out + test/tools/doclint/tidy/UnescapedOrUnknownEntity.java + test/tools/doclint/tidy/UnescapedOrUnknownEntity.out + test/tools/doclint/tidy/util/Main.java + test/tools/doclint/tidy/util/tidy.sh + test/tools/javac/diags/examples/NoContent.java Changeset: f20568328a57 Author: mcimadamore Date: 2012-12-17 16:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f20568328a57 8004099: Bad compiler diagnostic generated when poly expression is passed to non-existent method Summary: Some code paths in resolve do not use methodArguments to correctly format actuals Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/BadMethodCall2.java + test/tools/javac/lambda/BadMethodCall2.out Changeset: 064e372f273d Author: jjg Date: 2012-12-17 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/064e372f273d 8004961: rename Plugin.call to Plugin.init Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/plugin/showtype/ShowTypePlugin.java ! test/tools/javac/plugin/showtype/Test.java Changeset: ef537bcc825a Author: mchung Date: 2012-12-17 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ef537bcc825a 8005137: Rename DocLint.call to DocLint.init which overrides Plugin.init Reviewed-by: darcy, jjh ! src/share/classes/com/sun/tools/doclint/DocLint.java Changeset: bc74006c2d8d Author: darcy Date: 2012-12-18 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bc74006c2d8d 8005046: Provide checking for a default method in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java + test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 92fcf299cd09 Author: ohrstrom Date: 2012-12-18 10:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/92fcf299cd09 8004657: Add hooks to javac to enable reporting dependency information. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 250f0acf880c Author: mcimadamore Date: 2012-12-18 22:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/250f0acf880c 8005193: New regression test test/tools/javac/lambda/BadMethodCall2.java fails Summary: Bad golden file in negative test Reviewed-by: jjh ! test/tools/javac/lambda/BadMethodCall2.out Changeset: 573b38691a74 Author: lana Date: 2012-12-18 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/573b38691a74 Merge Changeset: 67b01d295cd2 Author: jjg Date: 2012-12-19 11:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/doclint/DocLintTest.java Changeset: f72c9c5aeaef Author: jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java Changeset: a22f23fb7abf Author: jjg Date: 2012-12-20 17:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a22f23fb7abf 8005307: fix missing @bug tags Reviewed-by: jjh ! test/tools/doclint/AccessTest.java ! test/tools/doclint/AccessTest.package.out ! test/tools/doclint/AccessTest.private.out ! test/tools/doclint/AccessTest.protected.out ! test/tools/doclint/AccessTest.public.out ! test/tools/doclint/AccessibilityTest.java ! test/tools/doclint/AccessibilityTest.out ! test/tools/doclint/EmptyAuthorTest.java ! test/tools/doclint/EmptyAuthorTest.out ! test/tools/doclint/EmptyExceptionTest.java ! test/tools/doclint/EmptyExceptionTest.out ! test/tools/doclint/EmptyParamTest.java ! test/tools/doclint/EmptyParamTest.out ! test/tools/doclint/EmptyReturnTest.java ! test/tools/doclint/EmptyReturnTest.out ! test/tools/doclint/EmptySerialDataTest.java ! test/tools/doclint/EmptySerialDataTest.out ! test/tools/doclint/EmptySerialFieldTest.java ! test/tools/doclint/EmptySerialFieldTest.out ! test/tools/doclint/EmptySinceTest.java ! test/tools/doclint/EmptySinceTest.out ! test/tools/doclint/EmptyVersionTest.java ! test/tools/doclint/EmptyVersionTest.out ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out ! test/tools/doclint/MissingParamsTest.java ! test/tools/doclint/MissingParamsTest.out ! test/tools/doclint/MissingReturnTest.java ! test/tools/doclint/MissingReturnTest.out ! test/tools/doclint/MissingThrowsTest.java ! test/tools/doclint/MissingThrowsTest.out ! test/tools/doclint/OptionTest.java ! test/tools/doclint/OverridesTest.java ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out ! test/tools/doclint/RunTest.java ! test/tools/doclint/SyntaxTest.java ! test/tools/doclint/SyntaxTest.out ! test/tools/doclint/SyntheticTest.java ! test/tools/doclint/ValidTest.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/tools/doclint/tidy/BadEnd.java ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/InsertImplicit.java ! test/tools/doclint/tidy/InsertImplicit.out ! test/tools/doclint/tidy/InvalidEntity.java ! test/tools/doclint/tidy/InvalidEntity.out ! test/tools/doclint/tidy/InvalidName.java ! test/tools/doclint/tidy/InvalidName.out ! test/tools/doclint/tidy/InvalidTag.java ! test/tools/doclint/tidy/InvalidTag.out ! test/tools/doclint/tidy/InvalidURI.java ! test/tools/doclint/tidy/InvalidURI.out ! test/tools/doclint/tidy/MissingGT.java ! test/tools/doclint/tidy/MissingGT.out ! test/tools/doclint/tidy/MissingTag.java ! test/tools/doclint/tidy/MissingTag.out ! test/tools/doclint/tidy/NestedTag.java ! test/tools/doclint/tidy/NestedTag.out ! test/tools/doclint/tidy/ParaInPre.java ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/RepeatedAttr.java ! test/tools/doclint/tidy/RepeatedAttr.out ! test/tools/doclint/tidy/TextNotAllowed.java ! test/tools/doclint/tidy/TextNotAllowed.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.java ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.out Changeset: b52a38d4536c Author: darcy Date: 2012-12-21 08:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b52a38d4536c 8005282: Use @library tag with non-relative path for javac tests Reviewed-by: jjg ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/classreader/T7031108.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/options/T7022337.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/6994946/SemanticErrorTest.java ! test/tools/javac/processing/6994946/SyntaxErrorTest.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/T7196462.java ! test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/TestContext.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/TestErrorCount.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestGetResource2.java ! test/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/tools/javac/processing/filer/TestLastRound.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/filer/TestValidRelativeNames.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingClass.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/element/TestTypeParameter.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/tools/javac/processing/werror/WError1.java ! test/tools/javac/processing/werror/WErrorGen.java ! test/tools/javac/processing/werror/WErrorLast.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/util/context/T7021650.java Changeset: 189b26e3818f Author: vromero Date: 2012-12-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/189b26e3818f 8003512: javac doesn't work with jar files with >64k entries Reviewed-by: jjg, ksrini Contributed-by: martinrb at google.com ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + test/tools/javac/file/zip/8003512/LoadClassFromJava6CreatedJarTest.java ! test/tools/javac/file/zip/Utils.java Changeset: 690c41cdab55 Author: bpatel Date: 2012-12-25 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/690c41cdab55 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg/A.java + test/com/sun/javadoc/testLambdaFeature/pkg/B.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags From chris.plummer at oracle.com Thu Jan 3 21:07:47 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 03 Jan 2013 21:07:47 -0800 Subject: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: References: Message-ID: <50E663A3.6020600@oracle.com> On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net wrote: > On 1/3/13 11:20 AM, Vitaly Davidovich wrote: >> >Vladimir, >> > >> >Unrelated to your change, but does CompileBroker::handle_full_code_cache() >> >need a ResourceMark since it calls stringStream::as_string()? Or is the RM >> >created somewhere in the caller chain? > File separate bug. I found several places with similar usage of > stringStream::as_string() without ResourceMark. > > What I missed in my review for this changes is that > CompileBroker::handle_full_code_cache() does not obtain CodeCache_lock > before calling CodeCache::print_summary(tty) which I think we need here. > Also it should be placed at the end of method after compilation is > switched off otherwise it will incorrectly print that compilation: enabled. > > Thanks, > Vladimir > Regarding obtaining CodeCache_lock, is this also a pre-exiting problem, or a new problem due to changes made in CodeCache::print_summary(tty). Chris > Code review for JDK-8005204 "Provide more detailed output on CodeCache > usage" > > We are adding more detailed output on CodeCache usage. > > Corresponding command line options are: > -XX:+PrintCodeCache - Will print the size of the codecache at VM > exit. It will include the total size, used size, maximum used size, maximum > free chunk, bounds, number of cached methods , etc. > -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, but does > so each time a method is compiled. This is useful if the app does not do a > normal JVM exit. > > Sample output: > > CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb > max_free_chunk=32226Kb > bounds [0xb414a000, 0xb41d2000, 0xb614a000] > total_blobs=131 nmethods=5 adapters=63 > compilation: enabled > > Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/ > > Sponsoring Alexander Harlap for that submission > From bengt.rutisson at oracle.com Thu Jan 3 21:29:01 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 04 Jan 2013 06:29:01 +0100 Subject: Result: CFV: New HSX Reviewer: Stefan Karlsson In-Reply-To: <50D29225.7000009@oracle.com> References: <50D29225.7000009@oracle.com> Message-ID: <50E6689D.2000009@oracle.com> Voting for Stefan Karlsson is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt Rutisson On 12/20/12 5:20 AM, Bengt Rutisson wrote: > > I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1]. > > Stefan is on his third year as a Committer on the HSX project. He is a > key contributor in the Hotspot's GC group, working on all GCs. He has > contributed 32 significant changesets as a Committer and is thus > well-qualified to be a Reviewer on the HSX project. > > Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week > voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Bengt Rutisson > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From vladimir.kozlov at oracle.com Thu Jan 3 22:35:56 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 22:35:56 -0800 Subject: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: <50E663A3.6020600@oracle.com> References: <50E663A3.6020600@oracle.com> Message-ID: <50E6784C.3030606@oracle.com> On 1/3/13 9:07 PM, Chris Plummer wrote: > On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net wrote: >> On 1/3/13 11:20 AM, Vitaly Davidovich wrote: >>> >Vladimir, >>> > >>> >Unrelated to your change, but does >>> CompileBroker::handle_full_code_cache() >>> >need a ResourceMark since it calls stringStream::as_string()? Or is >>> the RM >>> >created somewhere in the caller chain? >> File separate bug. I found several places with similar usage of >> stringStream::as_string() without ResourceMark. >> >> What I missed in my review for this changes is that >> CompileBroker::handle_full_code_cache() does not obtain CodeCache_lock >> before calling CodeCache::print_summary(tty) which I think we need here. >> Also it should be placed at the end of method after compilation is >> switched off otherwise it will incorrectly print that compilation: >> enabled. >> >> Thanks, >> Vladimir >> > Regarding obtaining CodeCache_lock, is this also a pre-exiting problem, > or a new problem due to changes made in CodeCache::print_summary(tty). Preexisting problem but it would be nice to fix it since we touching this code. Vladimir > > Chris > >> Code review for JDK-8005204 "Provide more detailed output on CodeCache >> usage" >> >> We are adding more detailed output on CodeCache usage. >> >> Corresponding command line options are: >> -XX:+PrintCodeCache - Will print the size of the codecache at VM >> exit. It will include the total size, used size, maximum used size, >> maximum >> free chunk, bounds, number of cached methods , etc. >> -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, but >> does >> so each time a method is compiled. This is useful if the app does not >> do a >> normal JVM exit. >> >> Sample output: >> >> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >> max_free_chunk=32226Kb >> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >> total_blobs=131 nmethods=5 adapters=63 >> compilation: enabled >> >> Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/ >> >> >> Sponsoring Alexander Harlap for that submission >> > From zhengyu.gu at oracle.com Fri Jan 4 08:24:12 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 04 Jan 2013 11:24:12 -0500 Subject: Round 4: Code review request: JDK-8005048, NMT: #loaded classes needs to just show the # defined classes In-Reply-To: <50CF7C73.7010608@oracle.com> References: <50CF7C73.7010608@oracle.com> Message-ID: <50E7022C.1030508@oracle.com> Previous fix could cause instance class counter go negative, since class list in ClassLoaderData contains none instance classes, and walking the list is not desirable. The new solution is to decrement counter in InstanceKlass::release_C_heap_structures. http://cr.openjdk.java.net/~zgu/8005048/webrev.03/ Thanks, -Zhengyu On 12/17/2012 3:11 PM, Zhengyu Gu wrote: > Current NMT implementation reports number of loaded classes at query > time, but number of defined classes is what is expected. > > This changset reflects two major changes: > > 1. It counts number of defined classes vs. number of loaded classes > 2. It counts number of defined classes for each generation, vs. counts > at query time. In this way, the number of defined classes that NMT > reports, should match the corresponding class metadata data. As the > result, the data should be more accurate. > > > Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/ > > > Thanks, > > -Zhengyu From alexander.harlap at oracle.com Fri Jan 4 10:55:47 2013 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Fri, 04 Jan 2013 13:55:47 -0500 Subject: Fwd: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: <438B8EFA-A2FB-4B39-BDB0-5E6953C38BCE@oracle.com> References: <50E6784C.3030606@oracle.com> <438B8EFA-A2FB-4B39-BDB0-5E6953C38BCE@oracle.com> Message-ID: <50E725B3.60202@oracle.com> New version of changeset uploaded to http://cr.openjdk.java.net/~vladidan/8005204/webrev.01/ Alex On 1/4/2013 7:52 AM, Vladimir Danushevsky wrote: > Alex, are you subscribed to this alias? Do you see the mails? > > Begin forwarded message: > >> *From: *Vladimir Kozlov > > >> *Date: *January 4, 2013 1:35:56 AM EST >> *To: *hotspot-dev at openjdk.java.net >> *Subject: **Re: RFR: 8005204: Provide more detailed output on >> CodeCache usage* >> >> On 1/3/13 9:07 PM, Chris Plummer wrote: >>> On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net >>> wrote: >>>> On 1/3/13 11:20 AM, Vitaly Davidovich wrote: >>>>> >Vladimir, >>>>> > >>>>> >Unrelated to your change, but does >>>>> CompileBroker::handle_full_code_cache() >>>>> >need a ResourceMark since it calls stringStream::as_string()? Or is >>>>> the RM >>>>> >created somewhere in the caller chain? >>>> File separate bug. I found several places with similar usage of >>>> stringStream::as_string() without ResourceMark. >>>> >>>> What I missed in my review for this changes is that >>>> CompileBroker::handle_full_code_cache() does not obtain CodeCache_lock >>>> before calling CodeCache::print_summary(tty) which I think we need >>>> here. >>>> Also it should be placed at the end of method after compilation is >>>> switched off otherwise it will incorrectly print that compilation: >>>> enabled. >>>> >>>> Thanks, >>>> Vladimir >>>> >>> Regarding obtaining CodeCache_lock, is this also a pre-exiting problem, >>> or a new problem due to changes made in CodeCache::print_summary(tty). >> >> Preexisting problem but it would be nice to fix it since we touching >> this code. >> >> Vladimir >> >>> >>> Chris >>> >>>> Code review for JDK-8005204 "Provide more detailed output on CodeCache >>>> usage" >>>> >>>> We are adding more detailed output on CodeCache usage. >>>> >>>> Corresponding command line options are: >>>> -XX:+PrintCodeCache - Will print the size of the codecache at VM >>>> exit. It will include the total size, used size, maximum used size, >>>> maximum >>>> free chunk, bounds, number of cached methods , etc. >>>> -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, but >>>> does >>>> so each time a method is compiled. This is useful if the app does not >>>> do a >>>> normal JVM exit. >>>> >>>> Sample output: >>>> >>>> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >>>> max_free_chunk=32226Kb >>>> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >>>> total_blobs=131 nmethods=5 adapters=63 >>>> compilation: enabled >>>> >>>> Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/>>> > >>>> >>>> >>>> Sponsoring Alexander Harlap for that submission >>>> >>> > From vladimir.kozlov at oracle.com Fri Jan 4 11:23:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Jan 2013 11:23:38 -0800 Subject: Fwd: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: <50E725B3.60202@oracle.com> References: <50E6784C.3030606@oracle.com> <438B8EFA-A2FB-4B39-BDB0-5E6953C38BCE@oracle.com> <50E725B3.60202@oracle.com> Message-ID: <50E72C3A.4040705@oracle.com> You forgot to pass 'detailed' parameter into print_summary() call. Otherwise looks good. Vladimir On 1/4/13 10:55 AM, Alexander Harlap wrote: > New version of changeset uploaded to > http://cr.openjdk.java.net/~vladidan/8005204/webrev.01/ > > > Alex > > On 1/4/2013 7:52 AM, Vladimir Danushevsky wrote: >> Alex, are you subscribed to this alias? Do you see the mails? >> >> Begin forwarded message: >> >>> *From: *Vladimir Kozlov >> > >>> *Date: *January 4, 2013 1:35:56 AM EST >>> *To: *hotspot-dev at openjdk.java.net >>> *Subject: **Re: RFR: 8005204: Provide more detailed output on >>> CodeCache usage* >>> >>> On 1/3/13 9:07 PM, Chris Plummer wrote: >>>> On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net >>>> wrote: >>>>> On 1/3/13 11:20 AM, Vitaly Davidovich wrote: >>>>>> >Vladimir, >>>>>> > >>>>>> >Unrelated to your change, but does >>>>>> CompileBroker::handle_full_code_cache() >>>>>> >need a ResourceMark since it calls stringStream::as_string()? Or is >>>>>> the RM >>>>>> >created somewhere in the caller chain? >>>>> File separate bug. I found several places with similar usage of >>>>> stringStream::as_string() without ResourceMark. >>>>> >>>>> What I missed in my review for this changes is that >>>>> CompileBroker::handle_full_code_cache() does not obtain CodeCache_lock >>>>> before calling CodeCache::print_summary(tty) which I think we need >>>>> here. >>>>> Also it should be placed at the end of method after compilation is >>>>> switched off otherwise it will incorrectly print that compilation: >>>>> enabled. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>> Regarding obtaining CodeCache_lock, is this also a pre-exiting problem, >>>> or a new problem due to changes made in CodeCache::print_summary(tty). >>> >>> Preexisting problem but it would be nice to fix it since we touching >>> this code. >>> >>> Vladimir >>> >>>> >>>> Chris >>>> >>>>> Code review for JDK-8005204 "Provide more detailed output on CodeCache >>>>> usage" >>>>> >>>>> We are adding more detailed output on CodeCache usage. >>>>> >>>>> Corresponding command line options are: >>>>> -XX:+PrintCodeCache - Will print the size of the codecache at VM >>>>> exit. It will include the total size, used size, maximum used size, >>>>> maximum >>>>> free chunk, bounds, number of cached methods , etc. >>>>> -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, but >>>>> does >>>>> so each time a method is compiled. This is useful if the app does not >>>>> do a >>>>> normal JVM exit. >>>>> >>>>> Sample output: >>>>> >>>>> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >>>>> max_free_chunk=32226Kb >>>>> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >>>>> total_blobs=131 nmethods=5 adapters=63 >>>>> compilation: enabled >>>>> >>>>> Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/>>>> > >>>>> >>>>> >>>>> Sponsoring Alexander Harlap for that submission >>>>> >>>> >> From alexander.harlap at oracle.com Fri Jan 4 12:12:44 2013 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Fri, 04 Jan 2013 15:12:44 -0500 Subject: Fwd: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: <50E72C3A.4040705@oracle.com> References: <50E6784C.3030606@oracle.com> <438B8EFA-A2FB-4B39-BDB0-5E6953C38BCE@oracle.com> <50E725B3.60202@oracle.com> <50E72C3A.4040705@oracle.com> Message-ID: <50E737BC.8040406@oracle.com> Sorry about that. Next version is here: http://cr.openjdk.java.net/~vladidan/8005204/webrev.02/ On 1/4/2013 2:23 PM, Vladimir Kozlov wrote: > You forgot to pass 'detailed' parameter into print_summary() call. > Otherwise looks good. > > Vladimir > > On 1/4/13 10:55 AM, Alexander Harlap wrote: >> New version of changeset uploaded to >> http://cr.openjdk.java.net/~vladidan/8005204/webrev.01/ >> >> >> Alex >> >> On 1/4/2013 7:52 AM, Vladimir Danushevsky wrote: >>> Alex, are you subscribed to this alias? Do you see the mails? >>> >>> Begin forwarded message: >>> >>>> *From: *Vladimir Kozlov >>> > >>>> *Date: *January 4, 2013 1:35:56 AM EST >>>> *To: *hotspot-dev at openjdk.java.net >>>> >>>> *Subject: **Re: RFR: 8005204: Provide more detailed output on >>>> CodeCache usage* >>>> >>>> On 1/3/13 9:07 PM, Chris Plummer wrote: >>>>> On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net >>>>> wrote: >>>>>> On 1/3/13 11:20 AM, Vitaly Davidovich wrote: >>>>>>> >Vladimir, >>>>>>> > >>>>>>> >Unrelated to your change, but does >>>>>>> CompileBroker::handle_full_code_cache() >>>>>>> >need a ResourceMark since it calls stringStream::as_string()? >>>>>>> Or is >>>>>>> the RM >>>>>>> >created somewhere in the caller chain? >>>>>> File separate bug. I found several places with similar usage of >>>>>> stringStream::as_string() without ResourceMark. >>>>>> >>>>>> What I missed in my review for this changes is that >>>>>> CompileBroker::handle_full_code_cache() does not obtain >>>>>> CodeCache_lock >>>>>> before calling CodeCache::print_summary(tty) which I think we need >>>>>> here. >>>>>> Also it should be placed at the end of method after compilation is >>>>>> switched off otherwise it will incorrectly print that compilation: >>>>>> enabled. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>> Regarding obtaining CodeCache_lock, is this also a pre-exiting >>>>> problem, >>>>> or a new problem due to changes made in >>>>> CodeCache::print_summary(tty). >>>> >>>> Preexisting problem but it would be nice to fix it since we touching >>>> this code. >>>> >>>> Vladimir >>>> >>>>> >>>>> Chris >>>>> >>>>>> Code review for JDK-8005204 "Provide more detailed output on >>>>>> CodeCache >>>>>> usage" >>>>>> >>>>>> We are adding more detailed output on CodeCache usage. >>>>>> >>>>>> Corresponding command line options are: >>>>>> -XX:+PrintCodeCache - Will print the size of the codecache >>>>>> at VM >>>>>> exit. It will include the total size, used size, maximum used size, >>>>>> maximum >>>>>> free chunk, bounds, number of cached methods , etc. >>>>>> -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, >>>>>> but >>>>>> does >>>>>> so each time a method is compiled. This is useful if the app does >>>>>> not >>>>>> do a >>>>>> normal JVM exit. >>>>>> >>>>>> Sample output: >>>>>> >>>>>> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >>>>>> max_free_chunk=32226Kb >>>>>> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >>>>>> total_blobs=131 nmethods=5 adapters=63 >>>>>> compilation: enabled >>>>>> >>>>>> Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/>>>>> >>>>>> > >>>>>> >>>>>> >>>>>> Sponsoring Alexander Harlap for that submission >>>>>> >>>>> >>> From vladimir.kozlov at oracle.com Fri Jan 4 12:26:56 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Jan 2013 12:26:56 -0800 Subject: Fwd: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: <50E737BC.8040406@oracle.com> References: <50E6784C.3030606@oracle.com> <438B8EFA-A2FB-4B39-BDB0-5E6953C38BCE@oracle.com> <50E725B3.60202@oracle.com> <50E72C3A.4040705@oracle.com> <50E737BC.8040406@oracle.com> Message-ID: <50E73B10.9020502@oracle.com> Good. Thanks, Vladimir On 1/4/13 12:12 PM, Alexander Harlap wrote: > Sorry about that. > > Next version is here: > http://cr.openjdk.java.net/~vladidan/8005204/webrev.02/ > > > On 1/4/2013 2:23 PM, Vladimir Kozlov wrote: >> You forgot to pass 'detailed' parameter into print_summary() call. >> Otherwise looks good. >> >> Vladimir >> >> On 1/4/13 10:55 AM, Alexander Harlap wrote: >>> New version of changeset uploaded to >>> http://cr.openjdk.java.net/~vladidan/8005204/webrev.01/ >>> >>> >>> Alex >>> >>> On 1/4/2013 7:52 AM, Vladimir Danushevsky wrote: >>>> Alex, are you subscribed to this alias? Do you see the mails? >>>> >>>> Begin forwarded message: >>>> >>>>> *From: *Vladimir Kozlov >>>> > >>>>> *Date: *January 4, 2013 1:35:56 AM EST >>>>> *To: *hotspot-dev at openjdk.java.net >>>>> >>>>> *Subject: **Re: RFR: 8005204: Provide more detailed output on >>>>> CodeCache usage* >>>>> >>>>> On 1/3/13 9:07 PM, Chris Plummer wrote: >>>>>> On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net >>>>>> wrote: >>>>>>> On 1/3/13 11:20 AM, Vitaly Davidovich wrote: >>>>>>>> >Vladimir, >>>>>>>> > >>>>>>>> >Unrelated to your change, but does >>>>>>>> CompileBroker::handle_full_code_cache() >>>>>>>> >need a ResourceMark since it calls stringStream::as_string()? >>>>>>>> Or is >>>>>>>> the RM >>>>>>>> >created somewhere in the caller chain? >>>>>>> File separate bug. I found several places with similar usage of >>>>>>> stringStream::as_string() without ResourceMark. >>>>>>> >>>>>>> What I missed in my review for this changes is that >>>>>>> CompileBroker::handle_full_code_cache() does not obtain >>>>>>> CodeCache_lock >>>>>>> before calling CodeCache::print_summary(tty) which I think we need >>>>>>> here. >>>>>>> Also it should be placed at the end of method after compilation is >>>>>>> switched off otherwise it will incorrectly print that compilation: >>>>>>> enabled. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>> Regarding obtaining CodeCache_lock, is this also a pre-exiting >>>>>> problem, >>>>>> or a new problem due to changes made in >>>>>> CodeCache::print_summary(tty). >>>>> >>>>> Preexisting problem but it would be nice to fix it since we touching >>>>> this code. >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> Chris >>>>>> >>>>>>> Code review for JDK-8005204 "Provide more detailed output on >>>>>>> CodeCache >>>>>>> usage" >>>>>>> >>>>>>> We are adding more detailed output on CodeCache usage. >>>>>>> >>>>>>> Corresponding command line options are: >>>>>>> -XX:+PrintCodeCache - Will print the size of the codecache >>>>>>> at VM >>>>>>> exit. It will include the total size, used size, maximum used size, >>>>>>> maximum >>>>>>> free chunk, bounds, number of cached methods , etc. >>>>>>> -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, >>>>>>> but >>>>>>> does >>>>>>> so each time a method is compiled. This is useful if the app does >>>>>>> not >>>>>>> do a >>>>>>> normal JVM exit. >>>>>>> >>>>>>> Sample output: >>>>>>> >>>>>>> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >>>>>>> max_free_chunk=32226Kb >>>>>>> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >>>>>>> total_blobs=131 nmethods=5 adapters=63 >>>>>>> compilation: enabled >>>>>>> >>>>>>> Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/>>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> Sponsoring Alexander Harlap for that submission >>>>>>> >>>>>> >>>> From karen.kinnear at oracle.com Fri Jan 4 12:54:04 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 4 Jan 2013 15:54:04 -0500 Subject: RFR:7199207 Placeholders cleanup Message-ID: Please review: http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading https://jbs.oracle.com/bugs/browse/JDK-7199207 Thanks to Stefan Karlsson for the initial analysis and the test case. Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). Tests run: Original test case from bug (linux 32 bit client) regression tests on solaris/sparc 32 bit: vm.sysdict.testlist vm.quick.testlist vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit java.lang.instrument: jtreg jli with -Xcomp ctw nightly.testlist tests in progress on solaris/sparc 32 bit: runThese -Xcomp jck vm thanks, Karen From eric.mccorkle at oracle.com Fri Jan 4 18:14:24 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 4 Jan 2013 21:14:24 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection Message-ID: Hello, Please review the following change set, which implements support for method parameter reflection in hotspot. The open webrev can be found here: http://cr.openjdk.java.net/~acorn/8004728/webrev The feature request can be found here http://bugs.sun.com/view_bug.do?bug_id=8004728 The latest version of the spec can be found here: http://cr.openjdk.java.net/~abuckley/8misc.pdf This has been posted to the list before, but it has since undergone testing and revision. I have run testlist (which runs *all* tests), and seen no new failures. Additionally, I have run several clean JPRT runs. Thanks, Eric From john.r.rose at oracle.com Fri Jan 4 22:39:59 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Jan 2013 22:39:59 -0800 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: References: Message-ID: <0914F860-6A86-41CC-9ED7-7CAEABCD659A@oracle.com> On Jan 4, 2013, at 6:14 PM, Eric McCorkle wrote: > Hello, > > Please review the following change set, which implements support for method parameter reflection in hotspot. The open webrev can be found here: > > http://cr.openjdk.java.net/~acorn/8004728/webrev Cool stuff! One quick comment on this loop in the CFP: + // Copy method parameters + if (method_parameters_length > 0) { + MethodParametersElement* elem = m->constMethod()->method_parameters_start(); + for(int i = 0; i < method_parameters_length; i++) { + elem[i].name_cp_index = + Bytes::get_Java_u2(method_parameters_data); + method_parameters_data += 2; + elem[i].flags = Bytes::get_Java_u4(method_parameters_data); + method_parameters_data += 4; + } + } This uses a C style (or C++ STL style) bumped pointer (*elemptr++). In the Hotspot source base is is more common, and preferable, to use the array/index style (array[index++]). In the case of the above code, the variable method_parameters_data starts off as the address of a classfile attribute, and is then repurposed as an index variable. It is misleading to give one name and one declaration to the two functions. For example, if code later on were to attempt to refer to method_parameters_data again, it would get garbage (the final value of the index). This sort of bug is a real possibility with single-name loop indexing, which the double-name idiom (array[index]) avoids cleanly. For a model of a similar job in the CFP, see this line and related lines: copy_lvt_element(&cf_lvt[idx], lvt); Note that cf_lvt is not incremented; the idx is instead. This is the preferred style in Hotspot. HTH ? John From john.r.rose at oracle.com Sat Jan 5 15:41:22 2013 From: john.r.rose at oracle.com (John Rose) Date: Sat, 5 Jan 2013 15:41:22 -0800 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: References: Message-ID: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> On Jan 4, 2013, at 6:14 PM, Eric McCorkle wrote: > Please review the following change set, which implements support for method parameter reflection in hotspot. The open webrev can be found here: > > http://cr.openjdk.java.net/~acorn/8004728/webrev Here are some more comments. The method java_lang_reflect_Parameter::index uses modifiers_offset, which isn't correct. I don't see any other errors like that. It would be best to test such things with asserts or even unit tests, although code this simple can usually be verified by inspection. I notice that the Parameter class is marked "Opt", which is good. In order to avoid surprise JVM crashes during testing, it should be the case that the changed JVM will work correctly with old versions of the JDK which lack Parameter.class, even with arbitrary inputs. I think Murphy's Law will bite if the JVM happens to load any class file that contains the new attribute. I suggest providing for this more explicitly: + } else if (method_attribute_name == vmSymbols::tag_method_parameters()) { + method_parameters_length = cfs->get_u1_fast(); + method_parameters_data = cfs->get_u1_buffer(); + cfs->skip_u2_fast(method_parameters_length); + cfs->skip_u4_fast(method_parameters_length; ++ if (!SystemDictionary::Parameter_klass_loaded()) ++ method_parameters_length = 0; // ignore this attribute if it cannot be reflected I think that's the only point necessary for such a check. (This path could be tested by manually removing Parameter.class from an rt.jar and running unit tests, or by injecting a typo into the name of the class in vmsymbols.hpp.) In general, version numbers, etc., will keep such bugs away, but it is better to be safe than sorry. In jvm.cpp and reflection.cpp there is some ambivalence about the method pointer argument for a Parameter factory method. Since the term "executable" is foreign to the JVM, and we just use the term "method" everywhere, I suggest using the word "executable" (confusing in the context of the JVM, and non-existent in reflection.cpp) only for the field in the Parameter itself (in javaClasses.hpp etc.). Use the word "method" elsewhere. The distinction between the JNI method argument and the JVM handle is often conveyed by a simple conventional prefix or suffix. Same general comment for the distinction between a reflective object and an internal metadata pointer. For example: +JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, jobject method_jh)) +{ + JVMWrapper("JVM_GetMethodParameters"); + // method is a handle to a java.lang.reflect.Method object + Handle reflected_method(THREAD, JNIHandles::resolve_non_null(method_jh)); + Method* method_oop = jvm_get_method_common(method, CHECK_NULL); + methodHandle method(THREAD, method_oop); Please avoid leading underscores in local variable names, so change _r to result_oop and _m to method_oop, or some such. There are pre-existing examples of this pattern in jvm.cpp, for example in JVM_DoPrivileged and JVM_FindClassFromClass. We use leading underscores only in limited ways, because of portability concerns. The subroutine jvm_get_method_common no longer needs to take a TRAPS argument, since the permgen removal. You can clean that up since you are in the same file, if you want. (There will be lots of little nits like this, after permgen removal. They can be adjusted on the fly, as we touch code.) Removing the "TRAPS" will make it possible to simplify your new code, since you won't need a CHECK_NULL and the extra method_oop temporary. The changes in constMethod.cpp look correct, but it's hard to tell. The code which manages the "inlined tables" is delicate and very sensitive to initialization ordering. You might try fault injection to ensure that the asserts will catch bugs. By that I mean moving the insertion around a bit in 'set_inlined_tables_length' and ensuring that you get an error diagnostic each time the code is out of place. Add asserts as needed. (Side note: I have some qualms about constMethod which are not due to your changes, but your changes expose a scaling problem in the coding pattern used. It appears to me that, given N inline tables, there are N(N+1)/2 code paths that need to be written correctly, and that a bug on any of those paths may stay latent until the exact pattern of inline-table bits shows up in practice. One symptom of this is the increasing levels of indentation in the logic (which could be clarified slightly by else-if chaining, BTW). Not sure what to do about this. I don't think there's a quick incremental fix. If we go after metadata footprint, I think all such metadata (if not frequently accessed) should be stored via compressed streams (CompressedWriteStream etc.), and that will provide a suitable moment to address this problem, but it's not in scope for this fix.) About whitespace: I was reviewing using the raw patch file, and saw a number of apparent oddities involving whitespace. They don't affect correctness, but it would be good to tidy them, to control excess noise in our code base. For example: template(java_lang_reflect_Field, "java/lang/reflect/Field") \ + template(java_lang_reflect_Parameter, "java/lang/reflect/Parameter") \ <== extra indent here - compressed_line_number_size, + compressed_line_number_size, <== changed indent here, with no apparent value add checked_exceptions_len, + method_parameters_len, <== one space extend, probably a diff+tab artifact generic_signature_index, + if(has_method_parameters()) { <== missing recommended space after 'if' + return has_generic_signature() ? (last_u2_element() - 1) : + last_u2_element(); <== tiny indent, should be horizontally aligned with previous expression, as with similar code nearby It's hard to tell for sure, since there are tabs in the diff, which a pre-push "jcheck" will reject. Although we (or our text editors) sometimes re-indent code we touch, it is often better to follow the ambient indentation, if the change would not improve readability or consistency. If you were re-aligning parameter declarations, that's a reasonable improvement; I'm not sure that's what you did because of the tabs. In some places you broke a parameter list onto multiple lines, which is fine. I updated the public style guide to clarify some of these points: https://wikis.oracle.com/display/HotSpotInternals/StyleGuide Thanks for making these changes. I think they will be taken up quickly by language implementors. ? John From karen.kinnear at oracle.com Mon Jan 7 09:02:02 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 7 Jan 2013 12:02:02 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: References: Message-ID: <33D9FD68-7E55-476E-A3AA-39159515A03F@oracle.com> Eric, Code looks good. Thank you for running the testlist. What platform did you run it on? Also - I assume that the unit test will be checked in with the reflection library code change. So the two remaining issues are: 1) how does this work with class redefinition? 2) how does this work serviceability agent? - see agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java for where to add fixes Please file additional bugs for those to fix for jdk8. It is ok to check this is in prior to fixing those because of the need to get this initial hotspot set of changes in to be able to get the core library changes in which depend on these. In general it is important to get all of the dependent functionality working before checking any of it in. Questions/comments: 1. test/Makefile Is there a reason you changed the jtreg version? Did someone ask you to? To do this you want to rerun all the jtreg tests :-) - or you could skip this change 2. constMethod.cpp/constMethod.hpp I realize that this is complex, and it would be good to file an rfe to make this less brittle and sync up with serviceability agent better. In the meantime, thank you for the improved comments and fix to the generic_signature_index Thank you for the comments in ConstMethod::set_inlined_tables_length. Could you possibly add a comment that serviceability agent knows about the actual ordering and needs to be changed if any fields are added here? 3. vmSynbols.hpp Please check spacing for line 89 thanks, Karen On Jan 4, 2013, at 9:14 PM, Eric McCorkle wrote: > Hello, > > Please review the following change set, which implements support for method parameter reflection in hotspot. The open webrev can be found here: > > http://cr.openjdk.java.net/~acorn/8004728/webrev > > The feature request can be found here > > http://bugs.sun.com/view_bug.do?bug_id=8004728 > > The latest version of the spec can be found here: > > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > > This has been posted to the list before, but it has since undergone testing and revision. > > I have run testlist (which runs *all* tests), and seen no new failures. Additionally, I have run several clean JPRT runs. > > Thanks, > Eric From eric.mccorkle at oracle.com Mon Jan 7 10:30:31 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 07 Jan 2013 13:30:31 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <33D9FD68-7E55-476E-A3AA-39159515A03F@oracle.com> References: <33D9FD68-7E55-476E-A3AA-39159515A03F@oracle.com> Message-ID: <50EB1447.1040705@oracle.com> On 01/07/13 12:02, Karen Kinnear wrote: > Eric, > > Code looks good. Thank you for running the testlist. What platform did you run it on? Linux (gentoo) amd64, 3.6.4 kernel version. > > Also - I assume that the unit test will be checked in with the reflection library code > change. > Yes, there is an end-to-end test done in the JDK side. The JDK side depends on symbols exported from the VM, so it cannot go in until this does. > So the two remaining issues are: > 1) how does this work with class redefinition? All the data for MethodParameters is stored in constMethod. When we discussed in person, you said that this would be ok (I personally lack in-depth knowledge of hotspot to be able to comment directly) > 2) how does this work serviceability agent? > - see agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java for where to add fixes > > Please file additional bugs for those to fix for jdk8. > > It is ok to check this is in prior to > fixing those because of the need to get this initial hotspot set of changes in to > be able to get the core library changes in which depend on these. In general it > is important to get all of the dependent functionality working before checking any of it in. > I will file bugs for this, as well as for the GenericTypeSignature field added to constMethod recently (which I believe has the same issue) > > Questions/comments: > > 1. test/Makefile > Is there a reason you changed the jtreg version? Did someone ask you to? > To do this you want to rerun all the jtreg tests :-) - or you could skip this change > That's a mistake. I believe I had to change it to get something to run on my machine. I will revert it prior to push. > 2. constMethod.cpp/constMethod.hpp > > I realize that this is complex, and it would be good to file an rfe to make this less > brittle and sync up with serviceability agent better. > I agree. I had some very subtle errors arise from this code. > In the meantime, thank you for the improved comments and fix to the > generic_signature_index > Thank you for the comments in ConstMethod::set_inlined_tables_length. > Could you possibly add a comment that serviceability agent knows about the actual ordering > and needs to be changed if any fields are added here? > That's a very good idea. Done. > 3. vmSynbols.hpp > Please check spacing for line 89 > Done. Thanks for your review and help, Karen! From eric.mccorkle at oracle.com Mon Jan 7 10:43:04 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 07 Jan 2013 13:43:04 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <0914F860-6A86-41CC-9ED7-7CAEABCD659A@oracle.com> References: <0914F860-6A86-41CC-9ED7-7CAEABCD659A@oracle.com> Message-ID: <50EB1738.5080504@oracle.com> On 01/05/13 01:39, John Rose wrote: > Cool stuff! One quick comment on this loop in the CFP: > > + // Copy method parameters > + if (method_parameters_length > 0) { > + MethodParametersElement* elem = m->constMethod()->method_parameters_start(); > + for(int i = 0; i < method_parameters_length; i++) { > + elem[i].name_cp_index = > + Bytes::get_Java_u2(method_parameters_data); > + method_parameters_data += 2; > + elem[i].flags = Bytes::get_Java_u4(method_parameters_data); > + method_parameters_data += 4; > + } > + } > > This uses a C style (or C++ STL style) bumped pointer (*elemptr++). > > In the Hotspot source base is is more common, and preferable, to use the array/index style (array[index++]). > I agree with this in principle; however, I'd like to leave this as is for now (though with the suggested variable name change made), if that's ok, for the following reasons: 1) I actually copied this way of doing this from another place in CFP (I forget exactly where) 2) MethodParameters data is heterogenous (ie composed of u2's and u4's interspersed), and bumping and casting a pointer is really the only way to read such data portably[0] 3) I know for certain that the code I have now works, and it is very easy to introduce subtle errors in this kind of code by revising it. 4) There is talk of completely reworking CFP at some point after SE8. [0]: As far as I'm aware, neither C nor C++ make any solid guarantees regarding the offsets of structure fields (I yield to any C++ language attorneys that say otherwise), and given that the u2 parameter_name_index comes before the u4 modifiers field (which is likely to result in a misaligned modifiers field, which compilers may attempt to correct), I'm not terribly comfortable trusting a compiler to generate the right offsets. From john.r.rose at oracle.com Mon Jan 7 11:32:02 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 7 Jan 2013 11:32:02 -0800 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <50EB1738.5080504@oracle.com> References: <0914F860-6A86-41CC-9ED7-7CAEABCD659A@oracle.com> <50EB1738.5080504@oracle.com> Message-ID: On Jan 7, 2013, at 10:43 AM, Eric McCorkle wrote: > I agree with this in principle; however, I'd like to leave this as is > for now (though with the suggested variable name change made), if that's > ok, for the following reasons: Yes, that's fine. It's good for us to note the global preference, for the record, especially since there are plenty of counter-examples. -- John (on my iPhone) From coleen.phillimore at oracle.com Mon Jan 7 11:42:03 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 07 Jan 2013 14:42:03 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> References: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> Message-ID: <50EB250B.7010600@oracle.com> John, Thank you for your thorough review of this. I have a couple of comments below. On 01/05/2013 06:41 PM, John Rose wrote: > On Jan 4, 2013, at 6:14 PM, Eric McCorkle wrote: > >> Please review the following change set, which implements support for method parameter reflection in hotspot. The open webrev can be found here: >> >> http://cr.openjdk.java.net/~acorn/8004728/webrev > Here are some more comments. > > The method java_lang_reflect_Parameter::index uses modifiers_offset, which isn't correct. I don't see any other errors like that. It would be best to test such things with asserts or even unit tests, although code this simple can usually be verified by inspection. > > I notice that the Parameter class is marked "Opt", which is good. In order to avoid surprise JVM crashes during testing, it should be the case that the changed JVM will work correctly with old versions of the JDK which lack Parameter.class, even with arbitrary inputs. I think Murphy's Law will bite if the JVM happens to load any class file that contains the new attribute. I suggest providing for this more explicitly: > > + } else if (method_attribute_name == vmSymbols::tag_method_parameters()) { > + method_parameters_length = cfs->get_u1_fast(); > + method_parameters_data = cfs->get_u1_buffer(); > + cfs->skip_u2_fast(method_parameters_length); > + cfs->skip_u4_fast(method_parameters_length; > ++ if (!SystemDictionary::Parameter_klass_loaded()) > ++ method_parameters_length = 0; // ignore this attribute if it cannot be reflected > > I think that's the only point necessary for such a check. (This path could be tested by manually removing Parameter.class from an rt.jar and running unit tests, or by injecting a typo into the name of the class in vmsymbols.hpp.) In general, version numbers, etc., will keep such bugs away, but it is better to be safe than sorry. > > In jvm.cpp and reflection.cpp there is some ambivalence about the method pointer argument for a Parameter factory method. Since the term "executable" is foreign to the JVM, and we just use the term "method" everywhere, I suggest using the word "executable" (confusing in the context of the JVM, and non-existent in reflection.cpp) only for the field in the Parameter itself (in javaClasses.hpp etc.). Use the word "method" elsewhere. The distinction between the JNI method argument and the JVM handle is often conveyed by a simple conventional prefix or suffix. Same general comment for the distinction between a reflective object and an internal metadata pointer. For example: > > +JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, jobject method_jh)) > +{ > + JVMWrapper("JVM_GetMethodParameters"); > + // method is a handle to a java.lang.reflect.Method object > + Handle reflected_method(THREAD, JNIHandles::resolve_non_null(method_jh)); > + Method* method_oop = jvm_get_method_common(method, CHECK_NULL); > + methodHandle method(THREAD, method_oop); > > Please avoid leading underscores in local variable names, so change _r to result_oop and _m to method_oop, or some such. There are pre-existing examples of this pattern in jvm.cpp, for example in JVM_DoPrivileged and JVM_FindClassFromClass. We use leading underscores only in limited ways, because of portability concerns. I agree, except method_oop isn't an oop, so method_pointer or golly, even m would be a better name. > The subroutine jvm_get_method_common no longer needs to take a TRAPS argument, since the permgen removal. You can clean that up since you are in the same file, if you want. (There will be lots of little nits like this, after permgen removal. They can be adjusted on the fly, as we touch code.) Removing the "TRAPS" will make it possible to simplify your new code, since you won't need a CHECK_NULL and the extra method_oop temporary. If Eric takes out the "TRAPS" parameter to get_method_common, he also needs to change these lines since TRAPS gives you THREAD. I still think it's a nice thing to do. KlassHandle kh(THREAD, k); Method* m = InstanceKlass::cast(kh())->method_with_idnum(slot); to Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); > > The changes in constMethod.cpp look correct, but it's hard to tell. The code which manages the "inlined tables" is delicate and very sensitive to initialization ordering. You might try fault injection to ensure that the asserts will catch bugs. By that I mean moving the insertion around a bit in 'set_inlined_tables_length' and ensuring that you get an error diagnostic each time the code is out of place. Add asserts as needed. > > (Side note: I have some qualms about constMethod which are not due to your changes, but your changes expose a scaling problem in the coding pattern used. It appears to me that, given N inline tables, there are N(N+1)/2 code paths that need to be written correctly, and that a bug on any of those paths may stay latent until the exact pattern of inline-table bits shows up in practice. One symptom of this is the increasing levels of indentation in the logic (which could be clarified slightly by else-if chaining, BTW). Not sure what to do about this. I don't think there's a quick incremental fix. If we go after metadata footprint, I think all such metadata (if not frequently accessed) should be stored via compressed streams (CompressedWriteStream etc.), and that will provide a suitable moment to address this problem, but it's not in scope for this fix.) I was also wondering if there was a better way to inline these optional tables in constMethod because I want to add the method annotations to each method (remove from Annotations* type). Thanks, coleen > About whitespace: I was reviewing using the raw patch file, and saw a number of apparent oddities involving whitespace. They don't affect correctness, but it would be good to tidy them, to control excess noise in our code base. For example: > > template(java_lang_reflect_Field, "java/lang/reflect/Field") \ > + template(java_lang_reflect_Parameter, "java/lang/reflect/Parameter") \ <== extra indent here > > - compressed_line_number_size, > + compressed_line_number_size, <== changed indent here, with no apparent value add > > checked_exceptions_len, > + method_parameters_len, <== one space extend, probably a diff+tab artifact > generic_signature_index, > > + if(has_method_parameters()) { <== missing recommended space after 'if' > > + return has_generic_signature() ? (last_u2_element() - 1) : > + last_u2_element(); <== tiny indent, should be horizontally aligned with previous expression, as with similar code nearby > > > It's hard to tell for sure, since there are tabs in the diff, which a pre-push "jcheck" will reject. > > Although we (or our text editors) sometimes re-indent code we touch, it is often better to follow the ambient indentation, if the change would not improve readability or consistency. If you were re-aligning parameter declarations, that's a reasonable improvement; I'm not sure that's what you did because of the tabs. In some places you broke a parameter list onto multiple lines, which is fine. > > I updated the public style guide to clarify some of these points: > https://wikis.oracle.com/display/HotSpotInternals/StyleGuide > > Thanks for making these changes. I think they will be taken up quickly by language implementors. > > ? John > From eric.mccorkle at oracle.com Mon Jan 7 12:04:57 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 07 Jan 2013 15:04:57 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> References: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> Message-ID: <50EB2A69.7020602@oracle.com> On 01/05/13 18:41, John Rose wrote: > The method java_lang_reflect_Parameter::index uses modifiers_offset, which isn't correct. I don't see any other errors like that. It would be best to test such things with asserts or even unit tests, although code this simple can usually be verified by inspection. > Fixed. Good eyes, John, thanks for catching it! > I notice that the Parameter class is marked "Opt", which is good. In order to avoid surprise JVM crashes during testing, it should be the case that the changed JVM will work correctly with old versions of the JDK which lack Parameter.class, even with arbitrary inputs. I think Murphy's Law will bite if the JVM happens to load any class file that contains the new attribute. I suggest providing for this more explicitly: > > + } else if (method_attribute_name == vmSymbols::tag_method_parameters()) { > + method_parameters_length = cfs->get_u1_fast(); > + method_parameters_data = cfs->get_u1_buffer(); > + cfs->skip_u2_fast(method_parameters_length); > + cfs->skip_u4_fast(method_parameters_length; > ++ if (!SystemDictionary::Parameter_klass_loaded()) > ++ method_parameters_length = 0; // ignore this attribute if it cannot be reflected > > I think that's the only point necessary for such a check. (This path could be tested by manually removing Parameter.class from an rt.jar and running unit tests, or by injecting a typo into the name of the class in vmsymbols.hpp.) In general, version numbers, etc., will keep such bugs away, but it is better to be safe than sorry. > Applied. It can also be tested by using the javac that now exists in langtools with the -parameter flag, and the current JDK, which does not have java.lang.reflect.Parameter. > In jvm.cpp and reflection.cpp there is some ambivalence about the method pointer argument for a Parameter factory method. Since the term "executable" is foreign to the JVM, and we just use the term "method" everywhere, I suggest using the word "executable" (confusing in the context of the JVM, and non-existent in reflection.cpp) only for the field in the Parameter itself (in javaClasses.hpp etc.). Use the word "method" elsewhere. The distinction between the JNI method argument and the JVM handle is often conveyed by a simple conventional prefix or suffix. Same general comment for the distinction between a reflective object and an internal metadata pointer. For example: > > +JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, jobject method_jh)) > +{ > + JVMWrapper("JVM_GetMethodParameters"); > + // method is a handle to a java.lang.reflect.Method object > + Handle reflected_method(THREAD, JNIHandles::resolve_non_null(method_jh)); > + Method* method_oop = jvm_get_method_common(method, CHECK_NULL); > + methodHandle method(THREAD, method_oop); > > Please avoid leading underscores in local variable names, so change _r to result_oop and _m to method_oop, or some such. There are pre-existing examples of this pattern in jvm.cpp, for example in JVM_DoPrivileged and JVM_FindClassFromClass. We use leading underscores only in limited ways, because of portability concerns. > Done. [PL designer]It'd be nice if languages had a "usable only once" declaration specifier[/PL designer] However, as Coleen pointed out Method* is not an oop. > The subroutine jvm_get_method_common no longer needs to take a TRAPS argument, since the permgen removal. You can clean that up since you are in the same file, if you want. (There will be lots of little nits like this, after permgen removal. They can be adjusted on the fly, as we touch code.) Removing the "TRAPS" will make it possible to simplify your new code, since you won't need a CHECK_NULL and the extra method_oop temporary. > Done, with thanks to Coleen. > The changes in constMethod.cpp look correct, but it's hard to tell. The code which manages the "inlined tables" is delicate and very sensitive to initialization ordering. You might try fault injection to ensure that the asserts will catch bugs. By that I mean moving the insertion around a bit in 'set_inlined_tables_length' and ensuring that you get an error diagnostic each time the code is out of place. Add asserts as needed. > > (Side note: I have some qualms about constMethod which are not due to your changes, but your changes expose a scaling problem in the coding pattern used. It appears to me that, given N inline tables, there are N(N+1)/2 code paths that need to be written correctly, and that a bug on any of those paths may stay latent until the exact pattern of inline-table bits shows up in practice. One symptom of this is the increasing levels of indentation in the logic (which could be clarified slightly by else-if chaining, BTW). Not sure what to do about this. I don't think there's a quick incremental fix. If we go after metadata footprint, I think all such metadata (if not frequently accessed) should be stored via compressed streams (CompressedWriteStream etc.), and that will provide a suitable moment to address this problem, but it's not in scope for this fix.) I've discussed this code at length with Karen. It is indeed very fragile, and I already did your suggested fault injection in the course of debugging (only it wasn't intentional). If something is added in the wrong order, the code fails, and not in any predictable or obvious way. I have ideas about how to revise it, but that should probably be addressed after SE8. > > About whitespace: I was reviewing using the raw patch file, and saw a number of apparent oddities involving whitespace. They don't affect correctness, but it would be good to tidy them, to control excess noise in our code base. For example: > > template(java_lang_reflect_Field, "java/lang/reflect/Field") \ > + template(java_lang_reflect_Parameter, "java/lang/reflect/Parameter") \ <== extra indent here > > - compressed_line_number_size, > + compressed_line_number_size, <== changed indent here, with no apparent value add > > checked_exceptions_len, > + method_parameters_len, <== one space extend, probably a diff+tab artifact > generic_signature_index, > > + if(has_method_parameters()) { <== missing recommended space after 'if' > > + return has_generic_signature() ? (last_u2_element() - 1) : > + last_u2_element(); <== tiny indent, should be horizontally aligned with previous expression, as with similar code nearby > > > It's hard to tell for sure, since there are tabs in the diff, which a pre-push "jcheck" will reject. > > Although we (or our text editors) sometimes re-indent code we touch, it is often better to follow the ambient indentation, if the change would not improve readability or consistency. If you were re-aligning parameter declarations, that's a reasonable improvement; I'm not sure that's what you did because of the tabs. In some places you broke a parameter list onto multiple lines, which is fine. > Fixed. RE parameter list: I'd re-indented them with emacs (which puts them all at the same column), but for some reason, the diff didn't seem to pick them up. I'll sort out the tabs issue prior to push. > I updated the public style guide to clarify some of these points: > https://wikis.oracle.com/display/HotSpotInternals/StyleGuide > > Thanks for making these changes. I think they will be taken up quickly by language implementors. > > ? John > From christian.thalinger at oracle.com Mon Jan 7 14:40:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 14:40:48 -0800 Subject: RFR: Some build fixes for gcc4.7 In-Reply-To: <1357592366.3314.15.camel@mercury> References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com> <1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com> <1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com> <50C7E843.9020006@oracle.com> <1355300366.1747.169.camel@mercury> <1357592366.3314.15.camel@mercury> Message-ID: On Jan 7, 2013, at 12:59 PM, Roman Kennke wrote: > Am Donnerstag, den 13.12.2012, 12:41 -0800 schrieb Christian Thalinger: >> On Dec 12, 2012, at 12:19 AM, Roman Kennke wrote: >> >>> Hi David, >>> >>>> From my perspective, there are the following proposed changes not >>> committed yet: >>> >>> 1. >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html >>> >>>> From that one, only the jdk part is missing: >>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>> >>> I think it's the only one with a bug-id even: >>> 8003868: fix shark for latest HotSpot and LLVM >>> >>> 2. Then there is the library_call build fixes. (Which have also been >>> proposed by Yasumasa Suenaga, which now got the bug id 8004898 and >>> Christian is working on it.) >>> >>> Then I posted a bunch of others on hotspot-compiler-dev (maybe >>> hotspot-dev would have been better?) >>> >>> 3. Fix OSR in Shark for non-empty incoming stack >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html >>> >>> This one got a little review by David Chase, for which I will send an >>> updated webrev soon. I was hoping to get some more feedback though, or >>> even a bug-id. >>> >>> 4. Implement deoptimization support in Shark >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html >>> >>> This one did not get any feedback yet, no bug-id either. >>> >>> 5. Fix volatile float field access in Shark >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html >>> >>> Same, no feedback, no bug-id. >>> >>> 6. Enable JSR292 support in Shark >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html >>> >>> Got some positive feedback from John Rose, but no bug id and no >>> progress. >>> >>> Please let me know if I should do anything different in the future >>> (different mailing list, different format, ..) Also, if it helps, I can >>> group all those changes into one big change, I just thought that it is >>> easier to review in logical chunks (otherwise the changes would >>> interleave and it's difficult to say what belongs to what). >> >> Currently we have some problems with JPRT so I waiting for that to be resolved. But I will take care of all the above. > > Hi, > > Is there any progress on these issues? Maybe at least give it a Bug ID > so it's not forgotten? Yes, and I'm sorry about that. Let me create some bugs right now. -- Chris > > Best regards, > Roman > > From rkennke at redhat.com Mon Jan 7 12:59:26 2013 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 07 Jan 2013 21:59:26 +0100 Subject: RFR: Some build fixes for gcc4.7 In-Reply-To: References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com> <1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com> <1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com> <50C7E843.9020006@oracle.com> <1355300366.1747.169.camel@mercury> Message-ID: <1357592366.3314.15.camel@mercury> Am Donnerstag, den 13.12.2012, 12:41 -0800 schrieb Christian Thalinger: > On Dec 12, 2012, at 12:19 AM, Roman Kennke wrote: > > > Hi David, > > > >> From my perspective, there are the following proposed changes not > > committed yet: > > > > 1. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html > > > >> From that one, only the jdk part is missing: > > http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > > > I think it's the only one with a bug-id even: > > 8003868: fix shark for latest HotSpot and LLVM > > > > 2. Then there is the library_call build fixes. (Which have also been > > proposed by Yasumasa Suenaga, which now got the bug id 8004898 and > > Christian is working on it.) > > > > Then I posted a bunch of others on hotspot-compiler-dev (maybe > > hotspot-dev would have been better?) > > > > 3. Fix OSR in Shark for non-empty incoming stack > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html > > > > This one got a little review by David Chase, for which I will send an > > updated webrev soon. I was hoping to get some more feedback though, or > > even a bug-id. > > > > 4. Implement deoptimization support in Shark > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html > > > > This one did not get any feedback yet, no bug-id either. > > > > 5. Fix volatile float field access in Shark > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html > > > > Same, no feedback, no bug-id. > > > > 6. Enable JSR292 support in Shark > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html > > > > Got some positive feedback from John Rose, but no bug id and no > > progress. > > > > Please let me know if I should do anything different in the future > > (different mailing list, different format, ..) Also, if it helps, I can > > group all those changes into one big change, I just thought that it is > > easier to review in logical chunks (otherwise the changes would > > interleave and it's difficult to say what belongs to what). > > Currently we have some problems with JPRT so I waiting for that to be resolved. But I will take care of all the above. Hi, Is there any progress on these issues? Maybe at least give it a Bug ID so it's not forgotten? Best regards, Roman From john.r.rose at oracle.com Mon Jan 7 15:04:48 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 7 Jan 2013 15:04:48 -0800 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <50EB2A69.7020602@oracle.com> References: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> <50EB2A69.7020602@oracle.com> Message-ID: On Jan 7, 2013, at 12:04 PM, Eric McCorkle wrote: > Done. [PL designer]It'd be nice if languages had a "usable only once" > declaration specifier[/PL designer] > > However, as Coleen pointed out Method* is not an oop. Sure enough. Now it's a different kind of managed pointer. >> I have some qualms about constMethod... > > I've discussed this code at length with Karen. It is indeed very > fragile, and I already did your suggested fault injection in the course > of debugging (only it wasn't intentional). If something is added in the > wrong order, the code fails, and not in any predictable or obvious way. The ideal would be to have "fail fast" with a diagnostic that would quickly point to the defect. Often we can arrange our asserts to do this, so that the error shakes out quickly in a fastdebug test run. But in this case it's tricky. > I have ideas about how to revise it, but that should probably be > addressed after SE8. Yes, I suppose so. IMO, the simplest way to go (with comparable or better compression) would be to have a bitmask, associated with a compressed offset or length table, followed by the compressed data itself, in a big block at the various derived offsets. Accessing any of the optional data streams would require unpacking the complete offset table, an operation on 1-2 cache lines. One advantage of this scheme would be that the order-sensitive aspects of the compression would be centralized in the offset table unpack logic. Also, a stream-oriented scheme would allow CompressedStreams to be used (for everything except maybe the bitmask), which would be a decisive density benefit. (Decisive for suitably chosen microbenchmarks, of course.) The usual FooStream idioms would make it easy and cheap to access the data. > RE parameter list: I'd re-indented them with emacs (which puts > them all at the same column), but for some reason, the diff didn't seem > to pick them up. I'll sort out the tabs issue prior to push. The webrev diff sometimes adds the "-w" or "-b" option, which obscures whitespace only changes. That's one reason I often prefer the *.patch file in the webrev. But the *.patch file is murked up by tabs. Probably the webrev script should refuse to process diffs containing tabs, since jcheck will refuse them eventually. I use Emacs in the same way. Sometimes if a multi-line parameter list is (say) past column 40 I will exdent manually, for the sake of readability. But, there are only a few rules written down about whitespace; consistency is usually the safest and most tasteful bet. ? John From rkennke at redhat.com Mon Jan 7 15:16:12 2013 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 08 Jan 2013 00:16:12 +0100 Subject: RFR: Some build fixes for gcc4.7 In-Reply-To: References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com> <1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com> <1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com> <50C7E843.9020006@oracle.com> <1355300366.1747.169.camel@mercury> <1357592366.3314.15.camel@mercury> Message-ID: <1357600572.3314.16.camel@mercury> Am Montag, den 07.01.2013, 14:40 -0800 schrieb Christian Thalinger: > On Jan 7, 2013, at 12:59 PM, Roman Kennke wrote: > > > Am Donnerstag, den 13.12.2012, 12:41 -0800 schrieb Christian Thalinger: > >> On Dec 12, 2012, at 12:19 AM, Roman Kennke wrote: > >> > >>> Hi David, > >>> > >>>> From my perspective, there are the following proposed changes not > >>> committed yet: > >>> > >>> 1. > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html > >>> > >>>> From that one, only the jdk part is missing: > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>> > >>> I think it's the only one with a bug-id even: > >>> 8003868: fix shark for latest HotSpot and LLVM > >>> > >>> 2. Then there is the library_call build fixes. (Which have also been > >>> proposed by Yasumasa Suenaga, which now got the bug id 8004898 and > >>> Christian is working on it.) > >>> > >>> Then I posted a bunch of others on hotspot-compiler-dev (maybe > >>> hotspot-dev would have been better?) > >>> > >>> 3. Fix OSR in Shark for non-empty incoming stack > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html > >>> > >>> This one got a little review by David Chase, for which I will send an > >>> updated webrev soon. I was hoping to get some more feedback though, or > >>> even a bug-id. > >>> > >>> 4. Implement deoptimization support in Shark > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html > >>> > >>> This one did not get any feedback yet, no bug-id either. > >>> > >>> 5. Fix volatile float field access in Shark > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html > >>> > >>> Same, no feedback, no bug-id. > >>> > >>> 6. Enable JSR292 support in Shark > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html > >>> > >>> Got some positive feedback from John Rose, but no bug id and no > >>> progress. > >>> > >>> Please let me know if I should do anything different in the future > >>> (different mailing list, different format, ..) Also, if it helps, I can > >>> group all those changes into one big change, I just thought that it is > >>> easier to review in logical chunks (otherwise the changes would > >>> interleave and it's difficult to say what belongs to what). > >> > >> Currently we have some problems with JPRT so I waiting for that to be resolved. But I will take care of all the above. > > > > Hi, > > > > Is there any progress on these issues? Maybe at least give it a Bug ID > > so it's not forgotten? > > Yes, and I'm sorry about that. Let me create some bugs right now. Thanks alot! Cheers, Roman From coleen.phillimore at oracle.com Mon Jan 7 17:05:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 07 Jan 2013 20:05:06 -0500 Subject: Round 4: Code review request: JDK-8005048, NMT: #loaded classes needs to just show the # defined classes In-Reply-To: <50E7022C.1030508@oracle.com> References: <50CF7C73.7010608@oracle.com> <50E7022C.1030508@oracle.com> Message-ID: <50EB70C2.6050901@oracle.com> Zhengyu, Round 4 looks good! thanks, Coleen On 1/4/2013 11:24 AM, Zhengyu Gu wrote: > Previous fix could cause instance class counter go negative, since > class list in ClassLoaderData contains none instance classes, and > walking the list is not desirable. > > The new solution is to decrement counter in > InstanceKlass::release_C_heap_structures. > > http://cr.openjdk.java.net/~zgu/8005048/webrev.03/ > > Thanks, > > -Zhengyu > > On 12/17/2012 3:11 PM, Zhengyu Gu wrote: >> Current NMT implementation reports number of loaded classes at query >> time, but number of defined classes is what is expected. >> >> This changset reflects two major changes: >> >> 1. It counts number of defined classes vs. number of loaded classes >> 2. It counts number of defined classes for each generation, vs. >> counts at query time. In this way, the number of defined classes that >> NMT reports, should match the corresponding class metadata data. As >> the result, the data should be more accurate. >> >> >> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu From eric.mccorkle at oracle.com Tue Jan 8 11:00:52 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 08 Jan 2013 14:00:52 -0500 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: <50EB250B.7010600@oracle.com> References: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> <50EB250B.7010600@oracle.com> Message-ID: <50EC6CE4.7080209@oracle.com> Thanks to all for their reviews. There is an updated version here: http://oklahoma.us.oracle.com/~cphillim/webrev/JDK-8004728/ On 01/07/13 14:42, Coleen Phillimore wrote: > > > John, Thank you for your thorough review of this. I have a couple of > comments below. > > On 01/05/2013 06:41 PM, John Rose wrote: >> On Jan 4, 2013, at 6:14 PM, Eric McCorkle wrote: >> >>> Please review the following change set, which implements support for >>> method parameter reflection in hotspot. The open webrev can be found >>> here: >>> >>> http://cr.openjdk.java.net/~acorn/8004728/webrev >> Here are some more comments. >> >> The method java_lang_reflect_Parameter::index uses modifiers_offset, >> which isn't correct. I don't see any other errors like that. It >> would be best to test such things with asserts or even unit tests, >> although code this simple can usually be verified by inspection. >> >> I notice that the Parameter class is marked "Opt", which is good. In >> order to avoid surprise JVM crashes during testing, it should be the >> case that the changed JVM will work correctly with old versions of the >> JDK which lack Parameter.class, even with arbitrary inputs. I think >> Murphy's Law will bite if the JVM happens to load any class file that >> contains the new attribute. I suggest providing for this more >> explicitly: >> >> + } else if (method_attribute_name == >> vmSymbols::tag_method_parameters()) { >> + method_parameters_length = cfs->get_u1_fast(); >> + method_parameters_data = cfs->get_u1_buffer(); >> + cfs->skip_u2_fast(method_parameters_length); >> + cfs->skip_u4_fast(method_parameters_length; >> ++ if (!SystemDictionary::Parameter_klass_loaded()) >> ++ method_parameters_length = 0; // ignore this attribute if it >> cannot be reflected >> >> I think that's the only point necessary for such a check. (This path >> could be tested by manually removing Parameter.class from an rt.jar >> and running unit tests, or by injecting a typo into the name of the >> class in vmsymbols.hpp.) In general, version numbers, etc., will keep >> such bugs away, but it is better to be safe than sorry. >> >> In jvm.cpp and reflection.cpp there is some ambivalence about the >> method pointer argument for a Parameter factory method. Since the >> term "executable" is foreign to the JVM, and we just use the term >> "method" everywhere, I suggest using the word "executable" (confusing >> in the context of the JVM, and non-existent in reflection.cpp) only >> for the field in the Parameter itself (in javaClasses.hpp etc.). Use >> the word "method" elsewhere. The distinction between the JNI method >> argument and the JVM handle is often conveyed by a simple conventional >> prefix or suffix. Same general comment for the distinction between a >> reflective object and an internal metadata pointer. For example: >> +JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, >> jobject method_jh)) >> +{ >> + JVMWrapper("JVM_GetMethodParameters"); >> + // method is a handle to a java.lang.reflect.Method object >> + Handle reflected_method(THREAD, >> JNIHandles::resolve_non_null(method_jh)); >> + Method* method_oop = jvm_get_method_common(method, CHECK_NULL); >> + methodHandle method(THREAD, method_oop); >> >> Please avoid leading underscores in local variable names, so change _r >> to result_oop and _m to method_oop, or some such. There are >> pre-existing examples of this pattern in jvm.cpp, for example in >> JVM_DoPrivileged and JVM_FindClassFromClass. We use leading >> underscores only in limited ways, because of portability concerns. > > I agree, except method_oop isn't an oop, so method_pointer or golly, > even m would be a better name. >> The subroutine jvm_get_method_common no longer needs to take a TRAPS >> argument, since the permgen removal. You can clean that up since you >> are in the same file, if you want. (There will be lots of little nits >> like this, after permgen removal. They can be adjusted on the fly, as >> we touch code.) Removing the "TRAPS" will make it possible to >> simplify your new code, since you won't need a CHECK_NULL and the >> extra method_oop temporary. > > > If Eric takes out the "TRAPS" parameter to get_method_common, he also > needs to change these lines since TRAPS gives you THREAD. I still > think it's a nice thing to do. > > KlassHandle kh(THREAD, k); > Method* m = InstanceKlass::cast(kh())->method_with_idnum(slot); > to > Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); >> >> The changes in constMethod.cpp look correct, but it's hard to tell. >> The code which manages the "inlined tables" is delicate and very >> sensitive to initialization ordering. You might try fault injection >> to ensure that the asserts will catch bugs. By that I mean moving the >> insertion around a bit in 'set_inlined_tables_length' and ensuring >> that you get an error diagnostic each time the code is out of place. >> Add asserts as needed. >> >> (Side note: I have some qualms about constMethod which are not due to >> your changes, but your changes expose a scaling problem in the coding >> pattern used. It appears to me that, given N inline tables, there are >> N(N+1)/2 code paths that need to be written correctly, and that a bug >> on any of those paths may stay latent until the exact pattern of >> inline-table bits shows up in practice. One symptom of this is the >> increasing levels of indentation in the logic (which could be >> clarified slightly by else-if chaining, BTW). Not sure what to do >> about this. I don't think there's a quick incremental fix. If we go >> after metadata footprint, I think all such metadata (if not frequently >> accessed) should be stored via compressed streams >> (CompressedWriteStream etc.), and that will provide a suitable moment >> to address this problem, but it's not in scope for this fix.) > > I was also wondering if there was a better way to inline these optional > tables in constMethod because I want to add the method annotations to > each method (remove from Annotations* type). > > Thanks, > coleen >> About whitespace: I was reviewing using the raw patch file, and saw a >> number of apparent oddities involving whitespace. They don't affect >> correctness, but it would be good to tidy them, to control excess >> noise in our code base. For example: >> >> template(java_lang_reflect_Field, >> "java/lang/reflect/Field") \ >> + template(java_lang_reflect_Parameter, >> "java/lang/reflect/Parameter") \ <== extra indent here >> >> - compressed_line_number_size, >> + compressed_line_number_size, <== changed indent >> here, with no apparent value add >> >> checked_exceptions_len, >> + method_parameters_len, <== one space extend, >> probably a diff+tab artifact >> generic_signature_index, >> >> + if(has_method_parameters()) { <== missing recommended space after >> 'if' >> >> + return has_generic_signature() ? (last_u2_element() - 1) : >> + last_u2_element(); <== tiny indent, should be horizontally >> aligned with previous expression, as with similar code nearby >> >> >> It's hard to tell for sure, since there are tabs in the diff, which a >> pre-push "jcheck" will reject. >> >> Although we (or our text editors) sometimes re-indent code we touch, >> it is often better to follow the ambient indentation, if the change >> would not improve readability or consistency. If you were re-aligning >> parameter declarations, that's a reasonable improvement; I'm not sure >> that's what you did because of the tabs. In some places you broke a >> parameter list onto multiple lines, which is fine. >> >> I updated the public style guide to clarify some of these points: >> https://wikis.oracle.com/display/HotSpotInternals/StyleGuide >> >> Thanks for making these changes. I think they will be taken up >> quickly by language implementors. >> >> ? John >> > From karen.kinnear at oracle.com Tue Jan 8 11:05:38 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 8 Jan 2013 14:05:38 -0500 Subject: Round 4: Code review request: JDK-8005048, NMT: #loaded classes needs to just show the # defined classes In-Reply-To: <50E7022C.1030508@oracle.com> References: <50CF7C73.7010608@oracle.com> <50E7022C.1030508@oracle.com> Message-ID: <2BAA6A5A-8159-4D7E-9FBF-64253C7735E3@oracle.com> Zhengyu, Looks good. Thanks for fixing this. Karen On Jan 4, 2013, at 11:24 AM, Zhengyu Gu wrote: > Previous fix could cause instance class counter go negative, since class list in ClassLoaderData contains none instance classes, and walking the list is not desirable. > > The new solution is to decrement counter in InstanceKlass::release_C_heap_structures. > > http://cr.openjdk.java.net/~zgu/8005048/webrev.03/ > > Thanks, > > -Zhengyu > > On 12/17/2012 3:11 PM, Zhengyu Gu wrote: >> Current NMT implementation reports number of loaded classes at query time, but number of defined classes is what is expected. >> >> This changset reflects two major changes: >> >> 1. It counts number of defined classes vs. number of loaded classes >> 2. It counts number of defined classes for each generation, vs. counts at query time. In this way, the number of defined classes that NMT reports, should match the corresponding class metadata data. As the result, the data should be more accurate. >> >> >> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu From zhengyu.gu at oracle.com Tue Jan 8 12:34:52 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 08 Jan 2013 15:34:52 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path Message-ID: <50EC82EC.7070102@oracle.com> This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: $JDK/lib $JRE/lib directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ Thanks, -Zhengyu From staffan.larsen at oracle.com Tue Jan 8 12:57:35 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Jan 2013 21:57:35 +0100 Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50EC82EC.7070102@oracle.com> References: <50EC82EC.7070102@oracle.com> Message-ID: Looks good! On 8 jan 2013, at 21:34, Zhengyu Gu wrote: > This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. > > In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: > > $JDK/lib > $JRE/lib > directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) > > > http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ > > > Thanks, > > -Zhengyu > From kelly.ohair at oracle.com Tue Jan 8 13:44:04 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 8 Jan 2013 13:44:04 -0800 Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50EC82EC.7070102@oracle.com> References: <50EC82EC.7070102@oracle.com> Message-ID: You are modifying the search path (PATH?) for the VM process? Doesn't that impact the entire process? And doesn't it impact more than just pdb files being found? Sorry for sticking my nose in here, but something tells me this needs a wider review than just the hotspot team. -kto On Jan 8, 2013, at 12:34 PM, Zhengyu Gu wrote: > This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. > > In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: > > $JDK/lib > $JRE/lib > directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) > > > http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ > > > Thanks, > > -Zhengyu > From daniel.daugherty at oracle.com Tue Jan 8 14:30:30 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 08 Jan 2013 15:30:30 -0700 Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: References: <50EC82EC.7070102@oracle.com> Message-ID: <50EC9E06.4080703@oracle.com> On 1/8/13 2:44 PM, Kelly O'Hair wrote: > You are modifying the search path (PATH?) for the VM process? Kelly, This code should be modifying the SymbolSearchPath: _pfn_SymSetSearchPath(hProcess, paths); Zhengyu, I'm reviewing this code now. Dan > Doesn't that impact the entire process? > And doesn't it impact more than just pdb files being found? > > Sorry for sticking my nose in here, but something tells me this needs a wider review than just the hotspot team. > > -kto > > On Jan 8, 2013, at 12:34 PM, Zhengyu Gu wrote: > >> This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. >> >> In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: >> >> $JDK/lib >> $JRE/lib >> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >> >> >> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >> >> >> Thanks, >> >> -Zhengyu >> > > From daniel.daugherty at oracle.com Tue Jan 8 15:03:53 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 08 Jan 2013 16:03:53 -0700 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50EC82EC.7070102@oracle.com> References: <50EC82EC.7070102@oracle.com> Message-ID: <50ECA5D9.5070404@oracle.com> On 1/8/13 1:34 PM, Zhengyu Gu wrote: > This is an enhancement that allows Windows decoder to search pdb files > that are created by FDS. > > In short, if FDS pdb files are downloaded into following paths, > Widnows decoder should be able to use them to decode stacks: > > $JDK/lib > $JRE/lib > directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) > > > http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ src/os/windows/vm/decoder_windows.hpp No comments. src/os/windows/vm/decoder_windows.cpp line 26: why add a blank line? lines 76-77: these seem a little longer than 80... line 80: int len = sizeof(paths); Should be sizeof(paths) - 1 to leave room for the NULL terminator. Otherwise, your final strncat() call in the sequence could append a NULL and overflow the paths buffer. line 130: if (dwAttrib != INVALID_FILE_ATTRIBUTES && line 131: dwAttrib & FILE_ATTRIBUTE_DIRECTORY) Putting parens around the bit-mask on line 131 would be more clear; not required, but more clear. Dan > > > Thanks, > > -Zhengyu > > > From john.r.rose at oracle.com Tue Jan 8 15:20:20 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 8 Jan 2013 15:20:20 -0800 Subject: Request for review: JDK-8004728 Hotspot support for parameter reflection In-Reply-To: References: <161CBAAF-7693-48EB-AA10-4E1C04380196@oracle.com> <50EB2A69.7020602@oracle.com> Message-ID: <78E84D1E-84B0-4FF1-8293-0805762A7A92@oracle.com> On Jan 7, 2013, at 3:04 PM, John Rose wrote: > Yes, I suppose so. IMO, the simplest way to go (with comparable or better compression) would be to have a bitmask, associated with a compressed offset or length table, followed by the compressed data itself, in a big block at the various derived offsets. Accessing any of the optional data streams would require unpacking the complete offset table, an operation on 1-2 cache lines. One advantage of this scheme would be that the order-sensitive aspects of the compression would be centralized in the offset table unpack logic. Also, a stream-oriented scheme would allow CompressedStreams to be used (for everything except maybe the bitmask), which would be a decisive density benefit. (Decisive for suitably chosen microbenchmarks, of course.) The usual FooStream idioms would make it easy and cheap to access the data. I built a working prototype of this approach, FTR. It's not integrated anywhere, but it works standalone. https://blogs.oracle.com/jrose/resource/hotspot/streamBundle.patch.zip ? John From vitalyd at gmail.com Tue Jan 8 16:43:21 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 19:43:21 -0500 Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50EC82EC.7070102@oracle.com> References: <50EC82EC.7070102@oracle.com> Message-ID: Is it safe to use char[] instead of TCHAR[] which can be a wide char for Unicode? Sent from my phone On Jan 8, 2013 3:35 PM, "Zhengyu Gu" wrote: > This is an enhancement that allows Windows decoder to search pdb files > that are created by FDS. > > In short, if FDS pdb files are downloaded into following paths, Widnows > decoder should be able to use them to decode stacks: > > $JDK/lib > $JRE/lib > directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) > > > http://cr.openjdk.java.net/~**zgu/7152671/webrev.01/ > > > Thanks, > > -Zhengyu > > From zhengyu.gu at oracle.com Tue Jan 8 17:06:12 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 08 Jan 2013 20:06:12 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ECA5D9.5070404@oracle.com> References: <50EC82EC.7070102@oracle.com> <50ECA5D9.5070404@oracle.com> Message-ID: <50ECC284.2010104@oracle.com> Hi Dan, Thank you for reviewing. On 1/8/2013 6:03 PM, Daniel D. Daugherty wrote: > On 1/8/13 1:34 PM, Zhengyu Gu wrote: >> This is an enhancement that allows Windows decoder to search pdb >> files that are created by FDS. >> >> In short, if FDS pdb files are downloaded into following paths, >> Widnows decoder should be able to use them to decode stacks: >> >> $JDK/lib >> $JRE/lib >> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >> >> >> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ > > src/os/windows/vm/decoder_windows.hpp > No comments. > > src/os/windows/vm/decoder_windows.cpp > line 26: why add a blank line? > > lines 76-77: these seem a little longer than 80... > Will fix them. > line 80: int len = sizeof(paths); > Should be sizeof(paths) - 1 to leave room for the NULL > terminator. > Otherwise, your final strncat() call in the sequence could append > a NULL and overflow the paths buffer. I do realize the string will be terminated by extra '\0'. It is handled by remaining buffer size checking code, which has "len > number of characters to be appended", so it is guaranteed an extra space for '\0' > > line 130: if (dwAttrib != INVALID_FILE_ATTRIBUTES && > line 131: dwAttrib & FILE_ATTRIBUTE_DIRECTORY) > Putting parens around the bit-mask on line 131 would > be more clear; not required, but more clear. Will do. Thanks, -Zhengyu > > Dan > > > >> >> >> Thanks, >> >> -Zhengyu >> >> >> > From zhengyu.gu at oracle.com Tue Jan 8 17:09:08 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 08 Jan 2013 20:09:08 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: References: <50EC82EC.7070102@oracle.com> Message-ID: <50ECC334.5060405@oracle.com> Hi Vitaly, Thanks for reviewing. JVM can be not compiled with wide char ... Thanks, -Zhengyu On 1/8/2013 7:43 PM, Vitaly Davidovich wrote: > > Is it safe to use char[] instead of TCHAR[] which can be a wide char > for Unicode? > > Sent from my phone > > On Jan 8, 2013 3:35 PM, "Zhengyu Gu" > wrote: > > This is an enhancement that allows Windows decoder to search pdb > files that are created by FDS. > > In short, if FDS pdb files are downloaded into following paths, > Widnows decoder should be able to use them to decode stacks: > > $JDK/lib > $JRE/lib > directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) > > > http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ > > > > Thanks, > > -Zhengyu > From vitalyd at gmail.com Tue Jan 8 17:14:42 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 20:14:42 -0500 Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ECC334.5060405@oracle.com> References: <50EC82EC.7070102@oracle.com> <50ECC334.5060405@oracle.com> Message-ID: That's pretty safe then :) Thanks Sent from my phone On Jan 8, 2013 8:09 PM, "Zhengyu Gu" wrote: > ** > Hi Vitaly, > > Thanks for reviewing. > > JVM can be not compiled with wide char ... > > Thanks, > > -Zhengyu > > On 1/8/2013 7:43 PM, Vitaly Davidovich wrote: > > Is it safe to use char[] instead of TCHAR[] which can be a wide char for > Unicode? > > Sent from my phone > On Jan 8, 2013 3:35 PM, "Zhengyu Gu" wrote: > >> This is an enhancement that allows Windows decoder to search pdb files >> that are created by FDS. >> >> In short, if FDS pdb files are downloaded into following paths, Widnows >> decoder should be able to use them to decode stacks: >> >> $JDK/lib >> $JRE/lib >> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >> >> >> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >> >> >> Thanks, >> >> -Zhengyu >> >> From daniel.daugherty at oracle.com Tue Jan 8 21:23:39 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 08 Jan 2013 22:23:39 -0700 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ECC284.2010104@oracle.com> References: <50EC82EC.7070102@oracle.com> <50ECA5D9.5070404@oracle.com> <50ECC284.2010104@oracle.com> Message-ID: <50ECFEDB.50208@oracle.com> On 1/8/13 6:06 PM, Zhengyu Gu wrote: > Hi Dan, > > Thank you for reviewing. You're very welcome. > > On 1/8/2013 6:03 PM, Daniel D. Daugherty wrote: >> On 1/8/13 1:34 PM, Zhengyu Gu wrote: >>> This is an enhancement that allows Windows decoder to search pdb >>> files that are created by FDS. >>> >>> In short, if FDS pdb files are downloaded into following paths, >>> Widnows decoder should be able to use them to decode stacks: >>> >>> $JDK/lib >>> $JRE/lib >>> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >>> >>> >>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >> >> src/os/windows/vm/decoder_windows.hpp >> No comments. >> >> src/os/windows/vm/decoder_windows.cpp >> line 26: why add a blank line? >> >> lines 76-77: these seem a little longer than 80... >> > Will fix them. Thanks. > >> line 80: int len = sizeof(paths); >> Should be sizeof(paths) - 1 to leave room for the NULL >> terminator. >> Otherwise, your final strncat() call in the sequence could >> append >> a NULL and overflow the paths buffer. > I do realize the string will be terminated by extra '\0'. It is > handled by remaining buffer size checking code, which has "len > > number of characters to be appended", so it is guaranteed an extra > space for '\0' Agreed. Your existing logic is correct. > >> >> line 130: if (dwAttrib != INVALID_FILE_ATTRIBUTES && >> line 131: dwAttrib & FILE_ATTRIBUTE_DIRECTORY) >> Putting parens around the bit-mask on line 131 would >> be more clear; not required, but more clear. > Will do. Thanks. Dan > > Thanks, > > -Zhengyu >> >> Dan >> >> >> >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> >> From jon.masamitsu at oracle.com Tue Jan 8 22:59:42 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 09 Jan 2013 06:59:42 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130109070003.97F994712F@hg.openjdk.java.net> Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! 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/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp From christian.tornqvist at oracle.com Wed Jan 9 00:02:31 2013 From: christian.tornqvist at oracle.com (=?utf-8?B?Q2hyaXN0aWFuIFTDtnJucXZpc3Q=?=) Date: Wed, 9 Jan 2013 00:02:31 -0800 (PST) Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50EC82EC.7070102@oracle.com> References: <50EC82EC.7070102@oracle.com> Message-ID: <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> Hi Zhengyu, Why do we need to add JDK/lib and JRE/lib to the symbol path? Looking at where the symbols are I would expect the symbol path to include the jvm.dll directory and JRE/bin ? Thanks, Christian -----Original Message----- From: Zhengyu Gu Sent: den 8 januari 2013 21:35 To: hotspot-dev at openjdk.java.net Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: $JDK/lib $JRE/lib directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ Thanks, -Zhengyu From david.holmes at oracle.com Wed Jan 9 02:42:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Jan 2013 20:42:26 +1000 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: References: Message-ID: <50ED4992.5000107@oracle.com> Hi Karen, Can't really comment on the validity or otherwise of the approach but one query: 811 // must throw error outside of owning lock 812 if (throw_circularity_error) { 813 ResourceMark rm(THREAD); 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); 815 } 816 817 if (HAS_PENDING_EXCEPTION || k.is_null()) { 818 return NULL; 819 } Is it the case that we can not have an exception pending if we need to throw the circularity error? If so should we should assert that. Otherwise are we concerned about the exception we will lose? David On 5/01/2013 6:54 AM, Karen Kinnear wrote: > Please review: > http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ > > bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading > https://jbs.oracle.com/bugs/browse/JDK-7199207 > > Thanks to Stefan Karlsson for the initial analysis and the test case. > > Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. > Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no > other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire > span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, > LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). > > Tests run: > Original test case from bug (linux 32 bit client) > regression tests on solaris/sparc 32 bit: > vm.sysdict.testlist > vm.quick.testlist > vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit > java.lang.instrument: jtreg > jli with -Xcomp > ctw nightly.testlist > tests in progress on solaris/sparc 32 bit: > runThese -Xcomp > jck vm > > thanks, > Karen > > From aph at redhat.com Wed Jan 9 03:44:48 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 09 Jan 2013 11:44:48 +0000 Subject: C2 compilation gives incorrect results Message-ID: <50ED5830.8080309@redhat.com> Here's a nice one, reported at bug 2396372. Test case at https://bugzilla.redhat.com/attachment.cgi?id=605282 The bug seems to have been in HotSpot for many years. The test case runs through many iterations until: $ java -XX:+PrintCompilation PolynomialRoot !!!!!!!!n=4 test 1431 !!!!!!!!n=4 test 1432 96 37 3 PolynomialRoot::root4 (1560 bytes) made not entrant 96 112 4 PolynomialRoot::root2 (183 bytes) 96 45 4 PolynomialRoot::checkValues (360 bytes) made not entrant Exception in thread "main" 97 56 ! 3 sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (356 bytes) made not entrant java.lang.RuntimeException: order=4 p[0]=-0.09965134319016089;p[1]=0.0;p[2]=0.30234383793894914;p[3]=-0.18180230156481425;p[4]=0.5206321058295245; x.r=0.134302716567836 x.i=0.4911858311805498 res/sabs=-0.03744084182425251 ims/sabs=0.007299470095647275 sabs=3.553068664639566 res=-0.13302988186347808 ims=0.02593551846531791 n=4 eps=1.0E-6 sabs>1/eps=false f1=true f2=true t=1432 at PolynomialRoot.checkValues(PolynomialRoot.java:424) at PolynomialRoot.testRoots(PolynomialRoot.java:491) at PolynomialRoot.main(PolynomialRoot.java:762) mercury:~ $ java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-aph_2013_01_09_11_31-b00) OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode) Andrew. From zhengyu.gu at oracle.com Wed Jan 9 06:17:38 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 09 Jan 2013 09:17:38 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> Message-ID: <50ED7C02.1080707@oracle.com> Good question. Dan, do you have any comments? Thanks, -Zhengyu On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: > Hi Zhengyu, > > Why do we need to add JDK/lib and JRE/lib to the symbol path? Looking at where the symbols are I would expect the symbol path to include the jvm.dll directory and JRE/bin ? > > Thanks, > Christian > > -----Original Message----- > From: Zhengyu Gu > Sent: den 8 januari 2013 21:35 > To: hotspot-dev at openjdk.java.net > Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path > > This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. > > In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: > > $JDK/lib > $JRE/lib > directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) > > > http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ > > > Thanks, > > -Zhengyu > From daniel.daugherty at oracle.com Wed Jan 9 06:43:17 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 09 Jan 2013 07:43:17 -0700 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ED7C02.1080707@oracle.com> References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> Message-ID: <50ED8205.5030109@oracle.com> On 1/9/13 7:17 AM, Zhengyu Gu wrote: > Good question. Good catch Christian! > > Dan, do you have any comments? Yes. I keep forgetting that Windows keeps libraries in the "bin" directory rather than in a "lib" directory like a "normal" system. :-) So when I filed the bug, I wrote: > The Windows decoder should add the following directories to the > symbol search path: > > $JAVA_HOME/lib > $JAVA_HOME/jre/lib > $JAVA_HOME/jre/bin/client > $JAVA_HOME/jre/bin/server In the above list, both "lib" names should be "bin". Dan > > Thanks, > > -Zhengyu > > > On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >> Hi Zhengyu, >> >> Why do we need to add JDK/lib and JRE/lib to the symbol path? Looking >> at where the symbols are I would expect the symbol path to include >> the jvm.dll directory and JRE/bin ? >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Zhengyu Gu >> Sent: den 8 januari 2013 21:35 >> To: hotspot-dev at openjdk.java.net >> Subject: Code review request: 7152671,RFE: Windows decoder should add >> some std dirs to the symbol search path >> >> This is an enhancement that allows Windows decoder to search pdb >> files that are created by FDS. >> >> In short, if FDS pdb files are downloaded into following paths, >> Widnows decoder should be able to use them to decode stacks: >> >> $JDK/lib >> $JRE/lib >> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >> >> >> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >> >> >> Thanks, >> >> -Zhengyu >> From zhengyu.gu at oracle.com Wed Jan 9 07:02:39 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 09 Jan 2013 10:02:39 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ED8205.5030109@oracle.com> References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> <50ED8205.5030109@oracle.com> Message-ID: <50ED868F.806@oracle.com> Hi Dan, Thanks for the clarification, I updated bug report. -Zhengyu On 1/9/2013 9:43 AM, Daniel D. Daugherty wrote: > On 1/9/13 7:17 AM, Zhengyu Gu wrote: >> Good question. > > Good catch Christian! > > >> >> Dan, do you have any comments? > > Yes. I keep forgetting that Windows keeps libraries in the "bin" > directory rather than in a "lib" directory like a "normal" system. :-) > So when I filed the bug, I wrote: > > > The Windows decoder should add the following directories to the > > symbol search path: > > > > $JAVA_HOME/lib > > $JAVA_HOME/jre/lib > > $JAVA_HOME/jre/bin/client > > $JAVA_HOME/jre/bin/server > > In the above list, both "lib" names should be "bin". > > Dan > >> >> Thanks, >> >> -Zhengyu >> >> >> On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >>> Hi Zhengyu, >>> >>> Why do we need to add JDK/lib and JRE/lib to the symbol path? >>> Looking at where the symbols are I would expect the symbol path to >>> include the jvm.dll directory and JRE/bin ? >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Zhengyu Gu >>> Sent: den 8 januari 2013 21:35 >>> To: hotspot-dev at openjdk.java.net >>> Subject: Code review request: 7152671,RFE: Windows decoder should >>> add some std dirs to the symbol search path >>> >>> This is an enhancement that allows Windows decoder to search pdb >>> files that are created by FDS. >>> >>> In short, if FDS pdb files are downloaded into following paths, >>> Widnows decoder should be able to use them to decode stacks: >>> >>> $JDK/lib >>> $JRE/lib >>> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >>> >>> >>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> > From zhengyu.gu at oracle.com Wed Jan 9 07:43:40 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 09 Jan 2013 10:43:40 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ED8205.5030109@oracle.com> References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> <50ED8205.5030109@oracle.com> Message-ID: <50ED902C.6000402@oracle.com> I updated webrev to reflect the comments from Dan and Christian. Also, I updated the bug report to correct search paths to $JAVA_HOME/bin $JAVA_HOME/jre/bin $JAVA_HOME/jre/bin/{client or server} http://cr.openjdk.java.net/~zgu/7152671/webrev.02/ Please review. Thanks, -Zhengyu On 1/9/2013 9:43 AM, Daniel D. Daugherty wrote: > On 1/9/13 7:17 AM, Zhengyu Gu wrote: >> Good question. > > Good catch Christian! > > >> >> Dan, do you have any comments? > > Yes. I keep forgetting that Windows keeps libraries in the "bin" > directory rather than in a "lib" directory like a "normal" system. :-) > So when I filed the bug, I wrote: > > > The Windows decoder should add the following directories to the > > symbol search path: > > > > $JAVA_HOME/lib > > $JAVA_HOME/jre/lib > > $JAVA_HOME/jre/bin/client > > $JAVA_HOME/jre/bin/server > > In the above list, both "lib" names should be "bin". > > Dan > >> >> Thanks, >> >> -Zhengyu >> >> >> On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >>> Hi Zhengyu, >>> >>> Why do we need to add JDK/lib and JRE/lib to the symbol path? >>> Looking at where the symbols are I would expect the symbol path to >>> include the jvm.dll directory and JRE/bin ? >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Zhengyu Gu >>> Sent: den 8 januari 2013 21:35 >>> To: hotspot-dev at openjdk.java.net >>> Subject: Code review request: 7152671,RFE: Windows decoder should >>> add some std dirs to the symbol search path >>> >>> This is an enhancement that allows Windows decoder to search pdb >>> files that are created by FDS. >>> >>> In short, if FDS pdb files are downloaded into following paths, >>> Widnows decoder should be able to use them to decode stacks: >>> >>> $JDK/lib >>> $JRE/lib >>> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >>> >>> >>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> > From staffan.larsen at oracle.com Wed Jan 9 08:04:49 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Jan 2013 17:04:49 +0100 Subject: Code review request: 7152671, RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ED902C.6000402@oracle.com> References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> <50ED8205.5030109@oracle.com> <50ED902C.6000402@oracle.com> Message-ID: Comment on line 134 says "jre", but should now say "bin". Thanks, /Staffan On 9 jan 2013, at 16:43, Zhengyu Gu wrote: > I updated webrev to reflect the comments from Dan and Christian. Also, I updated the bug report to correct search paths to > > $JAVA_HOME/bin > $JAVA_HOME/jre/bin > $JAVA_HOME/jre/bin/{client or server} > > > http://cr.openjdk.java.net/~zgu/7152671/webrev.02/ > > Please review. > > Thanks, > > -Zhengyu > > On 1/9/2013 9:43 AM, Daniel D. Daugherty wrote: >> On 1/9/13 7:17 AM, Zhengyu Gu wrote: >>> Good question. >> >> Good catch Christian! >> >> >>> >>> Dan, do you have any comments? >> >> Yes. I keep forgetting that Windows keeps libraries in the "bin" >> directory rather than in a "lib" directory like a "normal" system. :-) >> So when I filed the bug, I wrote: >> >> > The Windows decoder should add the following directories to the >> > symbol search path: >> > >> > $JAVA_HOME/lib >> > $JAVA_HOME/jre/lib >> > $JAVA_HOME/jre/bin/client >> > $JAVA_HOME/jre/bin/server >> >> In the above list, both "lib" names should be "bin". >> >> Dan >> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >>>> Hi Zhengyu, >>>> >>>> Why do we need to add JDK/lib and JRE/lib to the symbol path? Looking at where the symbols are I would expect the symbol path to include the jvm.dll directory and JRE/bin ? >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Zhengyu Gu >>>> Sent: den 8 januari 2013 21:35 >>>> To: hotspot-dev at openjdk.java.net >>>> Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path >>>> >>>> This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. >>>> >>>> In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: >>>> >>>> $JDK/lib >>>> $JRE/lib >>>> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >>>> >>>> >>>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >> From daniel.daugherty at oracle.com Wed Jan 9 08:14:28 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 09 Jan 2013 09:14:28 -0700 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> <50ED8205.5030109@oracle.com> <50ED902C.6000402@oracle.com> Message-ID: <50ED9764.2040908@oracle.com> line 134: // replaced 'jre' with 'lib' More precisely, the "lib" should now say "bin". Dan On 1/9/13 9:04 AM, Staffan Larsen wrote: > Comment on line 134 says "jre", but should now say "bin". > > Thanks, > /Staffan > > On 9 jan 2013, at 16:43, Zhengyu Gu wrote: > >> I updated webrev to reflect the comments from Dan and Christian. Also, I updated the bug report to correct search paths to >> >> $JAVA_HOME/bin >> $JAVA_HOME/jre/bin >> $JAVA_HOME/jre/bin/{client or server} >> >> >> http://cr.openjdk.java.net/~zgu/7152671/webrev.02/ >> >> Please review. >> >> Thanks, >> >> -Zhengyu >> >> On 1/9/2013 9:43 AM, Daniel D. Daugherty wrote: >>> On 1/9/13 7:17 AM, Zhengyu Gu wrote: >>>> Good question. >>> Good catch Christian! >>> >>> >>>> Dan, do you have any comments? >>> Yes. I keep forgetting that Windows keeps libraries in the "bin" >>> directory rather than in a "lib" directory like a "normal" system. :-) >>> So when I filed the bug, I wrote: >>> >>>> The Windows decoder should add the following directories to the >>>> symbol search path: >>>> >>>> $JAVA_HOME/lib >>>> $JAVA_HOME/jre/lib >>>> $JAVA_HOME/jre/bin/client >>>> $JAVA_HOME/jre/bin/server >>> In the above list, both "lib" names should be "bin". >>> >>> Dan >>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >>>>> Hi Zhengyu, >>>>> >>>>> Why do we need to add JDK/lib and JRE/lib to the symbol path? Looking at where the symbols are I would expect the symbol path to include the jvm.dll directory and JRE/bin ? >>>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> -----Original Message----- >>>>> From: Zhengyu Gu >>>>> Sent: den 8 januari 2013 21:35 >>>>> To: hotspot-dev at openjdk.java.net >>>>> Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path >>>>> >>>>> This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. >>>>> >>>>> In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: >>>>> >>>>> $JDK/lib >>>>> $JRE/lib >>>>> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From coleen.phillimore at oracle.com Wed Jan 9 08:17:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 09 Jan 2013 11:17:25 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: References: Message-ID: <50ED9815.4050202@oracle.com> Karen, In systemDictionary, why can't you throw circularity error sooner, like around line 726 (after you release the lock)? 811 // must throw error outside of owning lock 812 if (throw_circularity_error) { 813 ResourceMark rm(THREAD); 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); 815 } I guess this compiles but it should be THROW_MSG_NULL() instead of THROW_MSG_0(). gcc is likely to be picky about things like this in the future. There are some weird indentation around some of your changes, not caused by them, but could you clean up nearby indentation problems in systemDictionary? Line 367, 352-356 (should be initialization all in one line). I didn't see any others. They are small cosmetic changes. This change is great! Thank you for taking the time to clean this up. I can see this preventing all sorts of bugs in the future! Coleen On 1/4/2013 3:54 PM, Karen Kinnear wrote: > Please review: > http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ > > bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading > https://jbs.oracle.com/bugs/browse/JDK-7199207 > > Thanks to Stefan Karlsson for the initial analysis and the test case. > > Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. > Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no > other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire > span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, > LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). > > Tests run: > Original test case from bug (linux 32 bit client) > regression tests on solaris/sparc 32 bit: > vm.sysdict.testlist > vm.quick.testlist > vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit > java.lang.instrument: jtreg > jli with -Xcomp > ctw nightly.testlist > tests in progress on solaris/sparc 32 bit: > runThese -Xcomp > jck vm > > thanks, > Karen > > From zhengyu.gu at oracle.com Wed Jan 9 08:34:15 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 09 Jan 2013 11:34:15 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> <50ED8205.5030109@oracle.com> <50ED902C.6000402@oracle.com> Message-ID: <50ED9C07.8030104@oracle.com> Thanks for catching this. -Zhengyu On 1/9/2013 11:04 AM, Staffan Larsen wrote: > Comment on line 134 says "jre", but should now say "bin". > > Thanks, > /Staffan > > On 9 jan 2013, at 16:43, Zhengyu Gu wrote: > >> I updated webrev to reflect the comments from Dan and Christian. Also, I updated the bug report to correct search paths to >> >> $JAVA_HOME/bin >> $JAVA_HOME/jre/bin >> $JAVA_HOME/jre/bin/{client or server} >> >> >> http://cr.openjdk.java.net/~zgu/7152671/webrev.02/ >> >> Please review. >> >> Thanks, >> >> -Zhengyu >> >> On 1/9/2013 9:43 AM, Daniel D. Daugherty wrote: >>> On 1/9/13 7:17 AM, Zhengyu Gu wrote: >>>> Good question. >>> Good catch Christian! >>> >>> >>>> Dan, do you have any comments? >>> Yes. I keep forgetting that Windows keeps libraries in the "bin" >>> directory rather than in a "lib" directory like a "normal" system. :-) >>> So when I filed the bug, I wrote: >>> >>>> The Windows decoder should add the following directories to the >>>> symbol search path: >>>> >>>> $JAVA_HOME/lib >>>> $JAVA_HOME/jre/lib >>>> $JAVA_HOME/jre/bin/client >>>> $JAVA_HOME/jre/bin/server >>> In the above list, both "lib" names should be "bin". >>> >>> Dan >>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >>>>> Hi Zhengyu, >>>>> >>>>> Why do we need to add JDK/lib and JRE/lib to the symbol path? Looking at where the symbols are I would expect the symbol path to include the jvm.dll directory and JRE/bin ? >>>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> -----Original Message----- >>>>> From: Zhengyu Gu >>>>> Sent: den 8 januari 2013 21:35 >>>>> To: hotspot-dev at openjdk.java.net >>>>> Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path >>>>> >>>>> This is an enhancement that allows Windows decoder to search pdb files that are created by FDS. >>>>> >>>>> In short, if FDS pdb files are downloaded into following paths, Widnows decoder should be able to use them to decode stacks: >>>>> >>>>> $JDK/lib >>>>> $JRE/lib >>>>> directory where jvm.dll is loaded from. ($JRE/bin/{server or client}) >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From zhengyu.gu at oracle.com Wed Jan 9 08:56:14 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 09 Jan 2013 11:56:14 -0500 Subject: Code review request: 7152671,RFE: Windows decoder should add some std dirs to the symbol search path In-Reply-To: <50ED9764.2040908@oracle.com> References: <50EC82EC.7070102@oracle.com> <7ba6e024-9df9-4cd4-9b3a-0c5fce6a033c@default> <50ED7C02.1080707@oracle.com> <50ED8205.5030109@oracle.com> <50ED902C.6000402@oracle.com> <50ED9764.2040908@oracle.com> Message-ID: <50EDA12E.4020701@oracle.com> Yes. Fixed based on Staffan's comment. Thanks again. -Zhengyu On 1/9/2013 11:14 AM, Daniel D. Daugherty wrote: > line 134: // replaced 'jre' with 'lib' > More precisely, the "lib" should now say "bin". > > Dan > > > On 1/9/13 9:04 AM, Staffan Larsen wrote: >> Comment on line 134 says "jre", but should now say "bin". >> >> Thanks, >> /Staffan >> >> On 9 jan 2013, at 16:43, Zhengyu Gu wrote: >> >>> I updated webrev to reflect the comments from Dan and Christian. >>> Also, I updated the bug report to correct search paths to >>> >>> $JAVA_HOME/bin >>> $JAVA_HOME/jre/bin >>> $JAVA_HOME/jre/bin/{client or server} >>> >>> >>> http://cr.openjdk.java.net/~zgu/7152671/webrev.02/ >>> >>> Please review. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 1/9/2013 9:43 AM, Daniel D. Daugherty wrote: >>>> On 1/9/13 7:17 AM, Zhengyu Gu wrote: >>>>> Good question. >>>> Good catch Christian! >>>> >>>> >>>>> Dan, do you have any comments? >>>> Yes. I keep forgetting that Windows keeps libraries in the "bin" >>>> directory rather than in a "lib" directory like a "normal" system. :-) >>>> So when I filed the bug, I wrote: >>>> >>>>> The Windows decoder should add the following directories to the >>>>> symbol search path: >>>>> >>>>> $JAVA_HOME/lib >>>>> $JAVA_HOME/jre/lib >>>>> $JAVA_HOME/jre/bin/client >>>>> $JAVA_HOME/jre/bin/server >>>> In the above list, both "lib" names should be "bin". >>>> >>>> Dan >>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>> On 1/9/2013 3:02 AM, Christian T?rnqvist wrote: >>>>>> Hi Zhengyu, >>>>>> >>>>>> Why do we need to add JDK/lib and JRE/lib to the symbol path? >>>>>> Looking at where the symbols are I would expect the symbol path >>>>>> to include the jvm.dll directory and JRE/bin ? >>>>>> >>>>>> Thanks, >>>>>> Christian >>>>>> >>>>>> -----Original Message----- >>>>>> From: Zhengyu Gu >>>>>> Sent: den 8 januari 2013 21:35 >>>>>> To: hotspot-dev at openjdk.java.net >>>>>> Subject: Code review request: 7152671,RFE: Windows decoder should >>>>>> add some std dirs to the symbol search path >>>>>> >>>>>> This is an enhancement that allows Windows decoder to search pdb >>>>>> files that are created by FDS. >>>>>> >>>>>> In short, if FDS pdb files are downloaded into following paths, >>>>>> Widnows decoder should be able to use them to decode stacks: >>>>>> >>>>>> $JDK/lib >>>>>> $JRE/lib >>>>>> directory where jvm.dll is loaded from. ($JRE/bin/{server or >>>>>> client}) >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~zgu/7152671/webrev.01/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> > From ioi.lam at oracle.com Wed Jan 9 10:15:54 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 09 Jan 2013 10:15:54 -0800 Subject: RFR: 8005467 CDS size information Message-ID: <50EDB3DA.8010407@oracle.com> Please review: http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ bug: CDS size information is incorrect and unfriendly https://jbs.oracle.com/bugs/browse/JDK-8005467 Summary: The printed size information is changed from ro space: 0x000000000014718a out of 0x0000000000200000 words allocated at 0x0000000080000000. rw space: 0x000000000017a6ac out of 0x0000000000200000 words allocated at 0x0000000081000000. md space: 0x0000000000241a70 out of 0x0000000000400000 words allocated at 0x0000000082000000. mc space: 0x0000000000008505 out of 0x000000000001e000 words allocated at 0x0000000082400000. to ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] at 0x0000000080000000. rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% full] at 0x0000000081000000. md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% full] at 0x0000000082000000. mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% full] at 0x0000000082400000. total : 21178485 bytes There is otherwise no functional change. Tests run: + JPRT -- to verify build-ability + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 (32- and 64-bit VM) to verify the printed output is as expected. Thanks, Ioi From joseph.provino at oracle.com Wed Jan 9 11:48:43 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Wed, 09 Jan 2013 14:48:43 -0500 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Message-ID: <50EDC99B.9040109@oracle.com> INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. The webrev is here: http://cr.openjdk.java.net/~jprovino/8005915/webrev.00 Thanks. joe From christian.thalinger at oracle.com Wed Jan 9 12:20:37 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Jan 2013 12:20:37 -0800 Subject: RFR: 8005467 CDS size information In-Reply-To: <50EDB3DA.8010407@oracle.com> References: <50EDB3DA.8010407@oracle.com> Message-ID: On Jan 9, 2013, at 10:15 AM, Ioi Lam wrote: > Please review: > > http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ > > bug: CDS size information is incorrect and unfriendly > https://jbs.oracle.com/bugs/browse/JDK-8005467 > > > Summary: > > The printed size information is changed from > > ro space: 0x000000000014718a out of 0x0000000000200000 words allocated at 0x0000000080000000. > rw space: 0x000000000017a6ac out of 0x0000000000200000 words allocated at 0x0000000081000000. > md space: 0x0000000000241a70 out of 0x0000000000400000 words allocated at 0x0000000082000000. > mc space: 0x0000000000008505 out of 0x000000000001e000 words allocated at 0x0000000082400000. > > to > > ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] at 0x0000000080000000. > rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% full] at 0x0000000081000000. > md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% full] at 0x0000000082000000. > mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% full] at 0x0000000082400000. The "% total" and "% full" are confusing. Should this be "% of total"? > total : 21178485 bytes This is "total usage", I suppose. Could we also print "total allocated size"? -- Chris > > There is otherwise no functional change. > > > Tests run: > > + JPRT -- to verify build-ability > > + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 > (32- and 64-bit VM) to verify the printed output is as expected. > > Thanks, > Ioi > From vladimir.kozlov at oracle.com Wed Jan 9 12:26:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 12:26:59 -0800 Subject: C2 compilation gives incorrect results In-Reply-To: <50ED5830.8080309@redhat.com> References: <50ED5830.8080309@redhat.com> Message-ID: <50EDD293.7000906@oracle.com> Andrew, I was not able to reproduce it with jdk6 (and updates). It starts failing with 7u4. Do you see the same? And Christian created bug 8005956 for this issue. Thanks, Vladimir On 1/9/13 3:44 AM, Andrew Haley wrote: > Here's a nice one, reported at bug 2396372. Test case at > https://bugzilla.redhat.com/attachment.cgi?id=605282 > The bug seems to have been in HotSpot for many years. > > The test case runs through many iterations until: > > $ java -XX:+PrintCompilation PolynomialRoot > > !!!!!!!!n=4 test 1431 > !!!!!!!!n=4 test 1432 > 96 37 3 PolynomialRoot::root4 (1560 bytes) made not entrant > 96 112 4 PolynomialRoot::root2 (183 bytes) > 96 45 4 PolynomialRoot::checkValues (360 bytes) made not entrant > Exception in thread "main" 97 56 ! 3 sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (356 bytes) made not entrant > java.lang.RuntimeException: order=4 p[0]=-0.09965134319016089;p[1]=0.0;p[2]=0.30234383793894914;p[3]=-0.18180230156481425;p[4]=0.5206321058295245; > x.r=0.134302716567836 x.i=0.4911858311805498 > res/sabs=-0.03744084182425251 ims/sabs=0.007299470095647275 sabs=3.553068664639566 > res=-0.13302988186347808 ims=0.02593551846531791 n=4 eps=1.0E-6 sabs>1/eps=false f1=true f2=true t=1432 > at PolynomialRoot.checkValues(PolynomialRoot.java:424) > at PolynomialRoot.testRoots(PolynomialRoot.java:491) > at PolynomialRoot.main(PolynomialRoot.java:762) > > mercury:~ $ java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-aph_2013_01_09_11_31-b00) > OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode) > > Andrew. > From alexander.harlap at oracle.com Thu Jan 3 12:50:14 2013 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Thu, 03 Jan 2013 15:50:14 -0500 Subject: Fwd: RFR: 8005204: Provide more detailed output on CodeCache usage In-Reply-To: <0387838C-6263-4D61-A2DA-F8282AC5323D@oracle.com> References: <0387838C-6263-4D61-A2DA-F8282AC5323D@oracle.com> Message-ID: <50E5EF06.9050507@oracle.com> AdapterHandlerLibrary::get_adapter() in sharedRuntime.cpp has ResourceMark rm; AdapterHandlerLibrary::create_native_wrapper in shared Runtime.cpp has ResourceMark rm; CompileBroker::compiler_thread_loop() in compileBroker.cpp has ResourceMark rm; SharkCompiler::compile_method (it calls env->register_method()) has ResourceMark rm; Compile::Compile calls env->register_method() calls CompileBroker::handle_full_code_cache() -none has ResourceMark. Alex On 1/3/2013 2:22 PM, Vladimir Danushevsky wrote: > Alex, do you see that? > > Begin forwarded message: > >> *From: *Vitaly Davidovich > >> *Date: *January 3, 2013 2:20:42 PM EST >> *To: *Vladimir Danushevsky > > >> *Cc: *hotspot-dev developers > > >> *Subject: **Re: RFR: 8005204: Provide more detailed output on >> CodeCache usage* >> >> Vladimir, >> >> Unrelated to your change, but does >> CompileBroker::handle_full_code_cache() need a ResourceMark since it >> calls stringStream::as_string()? Or is the RM created somewhere in >> the caller chain? >> >> Thanks >> >> Sent from my phone >> >> On Jan 3, 2013 12:59 PM, "Vladimir Danushevsky" >> > > wrote: >> >> Code review for JDK-8005204 "Provide more detailed output on >> CodeCache usage" >> >> We are adding more detailed output on CodeCache usage. >> >> Corresponding command line options are: >> -XX:+PrintCodeCache - Will print the size of the codecache >> at VM exit. It will include the total size, used size, maximum >> used size, maximum free chunk, bounds, number of cached methods , >> etc. >> -XX:+PrintCodeCacheOnCompilation - Same as PrintCodeCache, >> but does so each time a method is compiled. This is useful if the >> app does not do a normal JVM exit. >> >> Sample output: >> >> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb >> max_free_chunk=32226Kb >> bounds [0xb414a000, 0xb41d2000, 0xb614a000] >> total_blobs=131 nmethods=5 adapters=63 >> compilation: enabled >> >> Changeset: >> http://cr.openjdk.java.net/~vladidan/8005204/webrev.00/ >> >> >> Sponsoring Alexander Harlap for that submission >> > From christian.thalinger at oracle.com Wed Jan 9 12:17:00 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Jan 2013 12:17:00 -0800 Subject: C2 compilation gives incorrect results In-Reply-To: <50ED5830.8080309@redhat.com> References: <50ED5830.8080309@redhat.com> Message-ID: <30F073D7-E755-4AED-B967-EF0DE1986D6C@oracle.com> [Moving to hotspot-compiler-dev; bcc'ing hotspot-dev.] On Jan 9, 2013, at 3:44 AM, Andrew Haley wrote: > Here's a nice one, reported at bug 2396372. Test case at > https://bugzilla.redhat.com/attachment.cgi?id=605282 > The bug seems to have been in HotSpot for many years. > > The test case runs through many iterations until: > > $ java -XX:+PrintCompilation PolynomialRoot > > !!!!!!!!n=4 test 1431 > !!!!!!!!n=4 test 1432 > 96 37 3 PolynomialRoot::root4 (1560 bytes) made not entrant > 96 112 4 PolynomialRoot::root2 (183 bytes) > 96 45 4 PolynomialRoot::checkValues (360 bytes) made not entrant > Exception in thread "main" 97 56 ! 3 sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (356 bytes) made not entrant > java.lang.RuntimeException: order=4 p[0]=-0.09965134319016089;p[1]=0.0;p[2]=0.30234383793894914;p[3]=-0.18180230156481425;p[4]=0.5206321058295245; > x.r=0.134302716567836 x.i=0.4911858311805498 > res/sabs=-0.03744084182425251 ims/sabs=0.007299470095647275 sabs=3.553068664639566 > res=-0.13302988186347808 ims=0.02593551846531791 n=4 eps=1.0E-6 sabs>1/eps=false f1=true f2=true t=1432 > at PolynomialRoot.checkValues(PolynomialRoot.java:424) > at PolynomialRoot.testRoots(PolynomialRoot.java:491) > at PolynomialRoot.main(PolynomialRoot.java:762) > > mercury:~ $ java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-aph_2013_01_09_11_31-b00) > OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode) Thanks for reporting this one, Andrew. I filed: 8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block It seems there is a problem in liveness analysis and a product VM produces wrong code. -- Chris > > Andrew. From ioi.lam at oracle.com Wed Jan 9 12:52:56 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 09 Jan 2013 12:52:56 -0800 Subject: RFR: 8005467 CDS size information In-Reply-To: References: <50EDB3DA.8010407@oracle.com> Message-ID: <50EDD8A8.7010102@oracle.com> On 01/09/2013 12:20 PM, Christian Thalinger wrote: > On Jan 9, 2013, at 10:15 AM, Ioi Lam wrote: > >> Please review: >> >> http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ >> >> bug: CDS size information is incorrect and unfriendly >> https://jbs.oracle.com/bugs/browse/JDK-8005467 >> >> >> Summary: >> >> The printed size information is changed from >> >> ro space: 0x000000000014718a out of 0x0000000000200000 words allocated at 0x0000000080000000. >> rw space: 0x000000000017a6ac out of 0x0000000000200000 words allocated at 0x0000000081000000. >> md space: 0x0000000000241a70 out of 0x0000000000400000 words allocated at 0x0000000082000000. >> mc space: 0x0000000000008505 out of 0x000000000001e000 words allocated at 0x0000000082400000. >> >> to >> >> ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] at 0x0000000080000000. >> rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% full] at 0x0000000081000000. >> md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% full] at 0x0000000082000000. >> mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% full] at 0x0000000082400000. > The "% total" and "% full" are confusing. Should this be "% of total"? > >> total : 21178485 bytes > This is "total usage", I suppose. Could we also print "total allocated size"? Hi Chris, Thanks for the review. Would this be clearer? ro space: 8287312 [ 39.1% of total] out of 16777216 bytes [49.4% occupied] at 0x0000000080000000 rw space: 11369872 [ 53.7% of total] out of 16777216 bytes [67.8% occupied] at 0x0000000081000000 md space: 1487248 [ 7.0% of total] out of 4194304 bytes [35.5% occupied] at 0x0000000082000000 mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% occupied] at 0x0000000082400000 total : 21178485 [100.0% of total] out of 37871616 bytes [55.9% occupied] Thanks - Ioi > -- Chris > >> There is otherwise no functional change. >> >> >> Tests run: >> >> + JPRT -- to verify build-ability >> >> + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 >> (32- and 64-bit VM) to verify the printed output is as expected. >> >> Thanks, >> Ioi >> From coleen.phillimore at oracle.com Wed Jan 9 13:16:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 09 Jan 2013 16:16:12 -0500 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS In-Reply-To: <50EDC99B.9040109@oracle.com> References: <50EDC99B.9040109@oracle.com> Message-ID: <50EDDE1C.40901@oracle.com> Joe, Thank you for doing this. The changes look good. Coleen On 1/9/2013 2:48 PM, Joe Provino wrote: > INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. > > SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. > > The webrev is here: > http://cr.openjdk.java.net/~jprovino/8005915/webrev.00 > > Thanks. > > joe From ioi.lam at oracle.com Wed Jan 9 14:21:03 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 09 Jan 2013 14:21:03 -0800 Subject: RFR: 8004823: Add VM support for type annotation reflection In-Reply-To: <8A89B42E-3357-4085-9EAC-62CDA90792EB@oracle.com> References: <50D0A247.20502@oracle.com> <8A89B42E-3357-4085-9EAC-62CDA90792EB@oracle.com> Message-ID: <50EDED4F.90609@oracle.com> Hi Joel, I found a possible issue with the new type annotation code (changset 35431a769282). Should this extra NULL check be added? diff -r 36171820ba15 src/share/vm/classfile/classFileParser.cpp --- a/src/share/vm/classfile/classFileParser.cpp Mon Jan 07 13:10:37 2013 -0800 +++ b/src/share/vm/classfile/classFileParser.cpp Wed Jan 09 13:48:39 2013 -0800 @@ -2467,11 +2467,13 @@ MetadataFactory::new_array(loader_data, length, NULL, CHECK_NULL); } (*methods_default_annotations)->at_put(index, method_default_annotations); *+ if (method_type_annotations != NULL) {** * if (*methods_type_annotations == NULL) { *methods_type_annotations = MetadataFactory::new_array(loader_data, length, NULL, CHECK_NULL); } (*methods_type_annotations)->at_put(index, method_type_annotations); *+ }** * } I am testing a HelloWorld program and all loaded classes (all of them from rt.jar) have a non-zero Annotations::type_annotation() field (all added up to about 64KB of data for about 400 loaded classes). After my patch above, the type_annotations take up zero bytes. Actually, the more I look at this block of code, it seems like a similar check should be done for methods_annotations, methods_parameter_annotations and methods_default_annotations as well (in classFileParser.cpp, just above the code quoted above). If we can avoid the allocation of these annotations arrays, for Eclipse, we can save about 4.2MB of allocations (with about 9000 loaded classes) on Linux/x64. Thanks - Ioi On 12/27/2012 04:57 AM, Joel Borggr?n-Franck wrote: > Thanks for the review John! > > I had this pushed before I saw this. I'll make sure to implement the checks when I start to implement retransform for type annotations in the VM. > > cheers > /Joel > > On Dec 20, 2012, at 10:10 PM, John Rose wrote: > >> This is good work. You can count me as a reviewer. >> >> One comment: There are a couple of places where a field index is used as an annotation array index (one old one new). I think it would be best to put an explicit range check like this: >> >> - if (md == NULL) >> + if (md == NULL || index() >= md->length()) >> return NULL; >> return md->at(index()); >> >> There are two reasons: First, although it is likely this is a needless check, the code which ensures length equality for field arrays and annotation arrays is buried in another file (classFileParser) and hard to check. Second, recent changes to classFileParser actually decouple the field array length from the value declared in the class file, by injecting extra fields into certain system classes. Although it is (again) unlikely that this will cause a problem, putting a local range check in the code above guarantees an adequate level of safety. >> >> The "at" method includes an assertion check, which is also good, but assertions are (a) not enabled in product mode and (b) can crash the VM if they fail. >> >> ? John >> >> On Dec 18, 2012, at 9:05 AM, Joel Borggr?n-Franck wrote: >> >>> New webrev up: >>> >>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/ >>> >>> - I had to rename the field name for the type annotation byte[] in Field, Constructor and Method. >>> >>> Also fixed: >>> >>> - I fixed the mapfile that got reindented. >>> - Added back a comment that I accidentally removed. From christian.thalinger at oracle.com Wed Jan 9 14:29:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Jan 2013 14:29:08 -0800 Subject: RFR: 8005467 CDS size information In-Reply-To: <50EDD8A8.7010102@oracle.com> References: <50EDB3DA.8010407@oracle.com> <50EDD8A8.7010102@oracle.com> Message-ID: <27BEA167-09B6-4612-9680-6252D1018CC5@oracle.com> On Jan 9, 2013, at 12:52 PM, Ioi Lam wrote: > On 01/09/2013 12:20 PM, Christian Thalinger wrote: >> On Jan 9, 2013, at 10:15 AM, Ioi Lam wrote: >> >>> Please review: >>> >>> http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ >>> >>> bug: CDS size information is incorrect and unfriendly >>> https://jbs.oracle.com/bugs/browse/JDK-8005467 >>> >>> >>> Summary: >>> >>> The printed size information is changed from >>> >>> ro space: 0x000000000014718a out of 0x0000000000200000 words allocated at 0x0000000080000000. >>> rw space: 0x000000000017a6ac out of 0x0000000000200000 words allocated at 0x0000000081000000. >>> md space: 0x0000000000241a70 out of 0x0000000000400000 words allocated at 0x0000000082000000. >>> mc space: 0x0000000000008505 out of 0x000000000001e000 words allocated at 0x0000000082400000. >>> >>> to >>> >>> ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] at 0x0000000080000000. >>> rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% full] at 0x0000000081000000. >>> md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% full] at 0x0000000082000000. >>> mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% full] at 0x0000000082400000. >> The "% total" and "% full" are confusing. Should this be "% of total"? >> >>> total : 21178485 bytes >> This is "total usage", I suppose. Could we also print "total allocated size"? > > Hi Chris, > > Thanks for the review. Would this be clearer? > > ro space: 8287312 [ 39.1% of total] out of 16777216 bytes [49.4% occupied] at 0x0000000080000000 > rw space: 11369872 [ 53.7% of total] out of 16777216 bytes [67.8% occupied] at 0x0000000081000000 > md space: 1487248 [ 7.0% of total] out of 4194304 bytes [35.5% occupied] at 0x0000000082000000 > mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% occupied] at 0x0000000082400000 > total : 21178485 [100.0% of total] out of 37871616 bytes [55.9% occupied] Much better. Thanks. -- Chris > > > Thanks > - Ioi > >> -- Chris >> >>> There is otherwise no functional change. >>> >>> >>> Tests run: >>> >>> + JPRT -- to verify build-ability >>> >>> + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 >>> (32- and 64-bit VM) to verify the printed output is as expected. >>> >>> Thanks, >>> Ioi >>> > From coleen.phillimore at oracle.com Wed Jan 9 17:07:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 09 Jan 2013 20:07:12 -0500 Subject: RFR: 8005467 CDS size information In-Reply-To: <27BEA167-09B6-4612-9680-6252D1018CC5@oracle.com> References: <50EDB3DA.8010407@oracle.com> <50EDD8A8.7010102@oracle.com> <27BEA167-09B6-4612-9680-6252D1018CC5@oracle.com> Message-ID: <50EE1440.5080609@oracle.com> How about "used"? GC uses "used" for such things. ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] at 0x0000000080000000. Thanks, Coleen On 1/9/2013 5:29 PM, Christian Thalinger wrote: > On Jan 9, 2013, at 12:52 PM, Ioi Lam wrote: > >> On 01/09/2013 12:20 PM, Christian Thalinger wrote: >>> On Jan 9, 2013, at 10:15 AM, Ioi Lam wrote: >>> >>>> Please review: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ >>>> >>>> bug: CDS size information is incorrect and unfriendly >>>> https://jbs.oracle.com/bugs/browse/JDK-8005467 >>>> >>>> >>>> Summary: >>>> >>>> The printed size information is changed from >>>> >>>> ro space: 0x000000000014718a out of 0x0000000000200000 words allocated at 0x0000000080000000. >>>> rw space: 0x000000000017a6ac out of 0x0000000000200000 words allocated at 0x0000000081000000. >>>> md space: 0x0000000000241a70 out of 0x0000000000400000 words allocated at 0x0000000082000000. >>>> mc space: 0x0000000000008505 out of 0x000000000001e000 words allocated at 0x0000000082400000. >>>> >>>> to >>>> >>>> ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] at 0x0000000080000000. >>>> rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% full] at 0x0000000081000000. >>>> md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% full] at 0x0000000082000000. >>>> mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% full] at 0x0000000082400000. >>> The "% total" and "% full" are confusing. Should this be "% of total"? >>> >>>> total : 21178485 bytes >>> This is "total usage", I suppose. Could we also print "total allocated size"? >> Hi Chris, >> >> Thanks for the review. Would this be clearer? >> >> ro space: 8287312 [ 39.1% of total] out of 16777216 bytes [49.4% occupied] at 0x0000000080000000 >> rw space: 11369872 [ 53.7% of total] out of 16777216 bytes [67.8% occupied] at 0x0000000081000000 >> md space: 1487248 [ 7.0% of total] out of 4194304 bytes [35.5% occupied] at 0x0000000082000000 >> mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% occupied] at 0x0000000082400000 >> total : 21178485 [100.0% of total] out of 37871616 bytes [55.9% occupied] > Much better. Thanks. -- Chris > >> >> Thanks >> - Ioi >> >>> -- Chris >>> >>>> There is otherwise no functional change. >>>> >>>> >>>> Tests run: >>>> >>>> + JPRT -- to verify build-ability >>>> >>>> + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 >>>> (32- and 64-bit VM) to verify the printed output is as expected. >>>> >>>> Thanks, >>>> Ioi >>>> From karen.kinnear at oracle.com Wed Jan 9 17:37:27 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 10 Jan 2013 01:37:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets Message-ID: <20130110013750.B3AF847161@hg.openjdk.java.net> Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From david.holmes at oracle.com Wed Jan 9 20:46:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2013 14:46:33 +1000 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS In-Reply-To: <50EDC99B.9040109@oracle.com> References: <50EDC99B.9040109@oracle.com> Message-ID: <50EE47A9.1060001@oracle.com> Looks okay to me. David On 10/01/2013 5:48 AM, Joe Provino wrote: > INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. > > SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. > > The webrev is here: http://cr.openjdk.java.net/~jprovino/8005915/webrev.00 > > Thanks. > > joe From bengt.rutisson at oracle.com Thu Jan 10 00:24:00 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 Jan 2013 09:24:00 +0100 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS In-Reply-To: <50EDC99B.9040109@oracle.com> References: <50EDC99B.9040109@oracle.com> Message-ID: <50EE7AA0.8050006@oracle.com> Hi Joe, Thanks for fixing this! I think it looks much better with INCLUDE_ALL_GCS in the code than SERIALGC. I think the changes look good, but we need to set up INCLUDE_ALL_GCS in the make files and not just in macros.hpp. There is nothing that requires source files to include marcros.hpp. If that include is missing and the source file contains a statement like: #if INCLUDE_ALL_GCS the value of INCLUDE_ALL_GCS will be interpreted as 0 and we will not get a compilation error. So, it is not enough to set INCLUDE_ALL_GCS to 0 in excludeSrc.make. We also need to set it to 1 for the default case. Also, just a reminder to inform Kelly about this change. I know that he has been asking everyone who updates make files to let him know about it to make sure that there are not conflicts with the build system changes. Thanks, Bengt On 1/9/13 8:48 PM, Joe Provino wrote: > INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. > > SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. > > The webrev is here: > http://cr.openjdk.java.net/~jprovino/8005915/webrev.00 > > Thanks. > > joe From dean.long at oracle.com Thu Jan 10 00:32:47 2013 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 10 Jan 2013 08:32:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130110083253.AD0A047174@hg.openjdk.java.net> Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/608b2e8a0063 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: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp From aleksey.shipilev at oracle.com Thu Jan 10 07:16:19 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 19:16:19 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation Message-ID: <50EEDB43.1050803@oracle.com> Hi, This is the final call for reviews for @Contended: http://cr.openjdk.java.net/~shade/8003985/webrev.01/ Changes: - VM: none since latest revision. - JDK: pruned some Javadocs as requested by CCC reviewers Testing: - (respin to make sure everything still intact) - Test8003985 passes on Linux x86_64 - JPRT builds passed - JPRT testing passed Status: - This change is ready to be pushed - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) - CCC is in place, and Approved I would need a sponsor to push this. Thanks, Aleksey. From karen.kinnear at oracle.com Thu Jan 10 07:19:35 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 10:19:35 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <50ED9815.4050202@oracle.com> References: <50ED9815.4050202@oracle.com> Message-ID: <1A3BB07C-0F9D-42F1-9765-054F5BAED35A@oracle.com> Coleen, I moved the throw of circularity to outside the new cleanup of the placeholder table entry, so we don't leave that unfreed. Good catch on the THROW_MSG_0 to THROW_MSG_NULL (same issue in multiple places) and THROW_MSG_CAUSE_0 - thanks! On Jan 9, 2013, at 11:17 AM, Coleen Phillimore wrote: > > Karen, > > In systemDictionary, why can't you throw circularity error sooner, like around line 726 (after you release the lock)? > > 811 // must throw error outside of owning lock > 812 if (throw_circularity_error) { > 813 ResourceMark rm(THREAD); > 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); > 815 } > > I guess this compiles but it should be THROW_MSG_NULL() instead of THROW_MSG_0(). gcc is likely to be picky about things like this in the future. > > There are some weird indentation around some of your changes, not caused by them, but could you clean up nearby indentation problems in systemDictionary? Line 367, 352-356 (should be initialization all in one line). I didn't see any others. They are small cosmetic changes. Fixed both thanks. > > This change is great! Thank you for taking the time to clean this up. I can see this preventing all sorts of bugs in the future! Thank you for the suggestion and for the code review, Karen > > Coleen > > On 1/4/2013 3:54 PM, Karen Kinnear wrote: >> Please review: >> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >> >> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >> https://jbs.oracle.com/bugs/browse/JDK-7199207 >> >> Thanks to Stefan Karlsson for the initial analysis and the test case. >> >> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >> >> Tests run: >> Original test case from bug (linux 32 bit client) >> regression tests on solaris/sparc 32 bit: >> vm.sysdict.testlist >> vm.quick.testlist >> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >> java.lang.instrument: jtreg >> jli with -Xcomp >> ctw nightly.testlist >> tests in progress on solaris/sparc 32 bit: >> runThese -Xcomp >> jck vm >> >> thanks, >> Karen >> >> > From karen.kinnear at oracle.com Thu Jan 10 07:46:49 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 10:46:49 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <50ED9815.4050202@oracle.com> References: <50ED9815.4050202@oracle.com> Message-ID: Coleen, Now I see what you were saying. I could put the circularity error earlier and assert that load_instance_added was false. That would be around 746 (after I release the lock). I will do that. That is much simpler. thanks for the suggestion, Karen On Jan 9, 2013, at 11:17 AM, Coleen Phillimore wrote: > > Karen, > > In systemDictionary, why can't you throw circularity error sooner, like around line 726 (after you release the lock)? > > 811 // must throw error outside of owning lock > 812 if (throw_circularity_error) { > 813 ResourceMark rm(THREAD); > 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); > 815 } > > I guess this compiles but it should be THROW_MSG_NULL() instead of THROW_MSG_0(). gcc is likely to be picky about things like this in the future. > > There are some weird indentation around some of your changes, not caused by them, but could you clean up nearby indentation problems in systemDictionary? Line 367, 352-356 (should be initialization all in one line). I didn't see any others. They are small cosmetic changes. > > This change is great! Thank you for taking the time to clean this up. I can see this preventing all sorts of bugs in the future! > > Coleen > > On 1/4/2013 3:54 PM, Karen Kinnear wrote: >> Please review: >> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >> >> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >> https://jbs.oracle.com/bugs/browse/JDK-7199207 >> >> Thanks to Stefan Karlsson for the initial analysis and the test case. >> >> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >> >> Tests run: >> Original test case from bug (linux 32 bit client) >> regression tests on solaris/sparc 32 bit: >> vm.sysdict.testlist >> vm.quick.testlist >> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >> java.lang.instrument: jtreg >> jli with -Xcomp >> ctw nightly.testlist >> tests in progress on solaris/sparc 32 bit: >> runThese -Xcomp >> jck vm >> >> thanks, >> Karen >> >> > From karen.kinnear at oracle.com Thu Jan 10 07:52:09 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 10:52:09 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <50ED4992.5000107@oracle.com> References: <50ED4992.5000107@oracle.com> Message-ID: <18F4AB83-566D-441C-A0A4-08FBE0E39181@oracle.com> David, Good question. I will add an assertion !HAS_PENDING_EXCEPTION before throwing the circularity error. And I moved it to right after releasing the lock, which is back to where it used to be, so I believe the only risk of a PENDING_EXCEPTION is if you called resolve_instance_class_or_null with one already. So can I count you as a code reviewer? thanks, Karen On Jan 9, 2013, at 5:42 AM, David Holmes wrote: > Hi Karen, > > Can't really comment on the validity or otherwise of the approach but one query: > > 811 // must throw error outside of owning lock > 812 if (throw_circularity_error) { > 813 ResourceMark rm(THREAD); > 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); > 815 } > 816 > 817 if (HAS_PENDING_EXCEPTION || k.is_null()) { > 818 return NULL; > 819 } > > Is it the case that we can not have an exception pending if we need to throw the circularity error? If so should we should assert that. Otherwise are we concerned about the exception we will lose? > > David > > On 5/01/2013 6:54 AM, Karen Kinnear wrote: >> Please review: >> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >> >> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >> https://jbs.oracle.com/bugs/browse/JDK-7199207 >> >> Thanks to Stefan Karlsson for the initial analysis and the test case. >> >> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >> >> Tests run: >> Original test case from bug (linux 32 bit client) >> regression tests on solaris/sparc 32 bit: >> vm.sysdict.testlist >> vm.quick.testlist >> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >> java.lang.instrument: jtreg >> jli with -Xcomp >> ctw nightly.testlist >> tests in progress on solaris/sparc 32 bit: >> runThese -Xcomp >> jck vm >> >> thanks, >> Karen >> >> From karen.kinnear at oracle.com Thu Jan 10 08:34:58 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 11:34:58 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <18F4AB83-566D-441C-A0A4-08FBE0E39181@oracle.com> References: <50ED4992.5000107@oracle.com> <18F4AB83-566D-441C-A0A4-08FBE0E39181@oracle.com> Message-ID: <1EBA2F30-B362-4668-AF8E-74783E3B3AFB@oracle.com> Updated webrev from both David and Coleen's suggestions (many thanks) http://cr.openjdk.java.net/~acorn/7199207.postreview/webrev Rerunning parallel_class_loading.testlist (which includes circularity testing) and sysdict. thanks, Karen On Jan 10, 2013, at 10:52 AM, Karen Kinnear wrote: > David, > > Good question. I will add an assertion !HAS_PENDING_EXCEPTION before throwing the > circularity error. And I moved it to right after releasing the lock, which is back to where it > used to be, so I believe the only risk of a PENDING_EXCEPTION is if you called > resolve_instance_class_or_null with one already. > > So can I count you as a code reviewer? > > thanks, > Karen > > On Jan 9, 2013, at 5:42 AM, David Holmes wrote: > >> Hi Karen, >> >> Can't really comment on the validity or otherwise of the approach but one query: >> >> 811 // must throw error outside of owning lock >> 812 if (throw_circularity_error) { >> 813 ResourceMark rm(THREAD); >> 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); >> 815 } >> 816 >> 817 if (HAS_PENDING_EXCEPTION || k.is_null()) { >> 818 return NULL; >> 819 } >> >> Is it the case that we can not have an exception pending if we need to throw the circularity error? If so should we should assert that. Otherwise are we concerned about the exception we will lose? >> >> David >> >> On 5/01/2013 6:54 AM, Karen Kinnear wrote: >>> Please review: >>> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >>> >>> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >>> https://jbs.oracle.com/bugs/browse/JDK-7199207 >>> >>> Thanks to Stefan Karlsson for the initial analysis and the test case. >>> >>> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >>> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >>> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >>> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >>> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >>> >>> Tests run: >>> Original test case from bug (linux 32 bit client) >>> regression tests on solaris/sparc 32 bit: >>> vm.sysdict.testlist >>> vm.quick.testlist >>> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >>> java.lang.instrument: jtreg >>> jli with -Xcomp >>> ctw nightly.testlist >>> tests in progress on solaris/sparc 32 bit: >>> runThese -Xcomp >>> jck vm >>> >>> thanks, >>> Karen >>> >>> > From coleen.phillimore at oracle.com Thu Jan 10 09:42:23 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Jan 2013 12:42:23 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <1EBA2F30-B362-4668-AF8E-74783E3B3AFB@oracle.com> References: <50ED4992.5000107@oracle.com> <18F4AB83-566D-441C-A0A4-08FBE0E39181@oracle.com> <1EBA2F30-B362-4668-AF8E-74783E3B3AFB@oracle.com> Message-ID: <50EEFD7F.0@oracle.com> Looks good! Coleen On 01/10/2013 11:34 AM, Karen Kinnear wrote: > Updated webrev from both David and Coleen's suggestions (many thanks) > > http://cr.openjdk.java.net/~acorn/7199207.postreview/webrev > > Rerunning parallel_class_loading.testlist (which includes circularity testing) and sysdict. > > thanks, > Karen > > On Jan 10, 2013, at 10:52 AM, Karen Kinnear wrote: > >> David, >> >> Good question. I will add an assertion !HAS_PENDING_EXCEPTION before throwing the >> circularity error. And I moved it to right after releasing the lock, which is back to where it >> used to be, so I believe the only risk of a PENDING_EXCEPTION is if you called >> resolve_instance_class_or_null with one already. >> >> So can I count you as a code reviewer? >> >> thanks, >> Karen >> >> On Jan 9, 2013, at 5:42 AM, David Holmes wrote: >> >>> Hi Karen, >>> >>> Can't really comment on the validity or otherwise of the approach but one query: >>> >>> 811 // must throw error outside of owning lock >>> 812 if (throw_circularity_error) { >>> 813 ResourceMark rm(THREAD); >>> 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); >>> 815 } >>> 816 >>> 817 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> 818 return NULL; >>> 819 } >>> >>> Is it the case that we can not have an exception pending if we need to throw the circularity error? If so should we should assert that. Otherwise are we concerned about the exception we will lose? >>> >>> David >>> >>> On 5/01/2013 6:54 AM, Karen Kinnear wrote: >>>> Please review: >>>> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >>>> >>>> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >>>> https://jbs.oracle.com/bugs/browse/JDK-7199207 >>>> >>>> Thanks to Stefan Karlsson for the initial analysis and the test case. >>>> >>>> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >>>> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >>>> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >>>> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >>>> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >>>> >>>> Tests run: >>>> Original test case from bug (linux 32 bit client) >>>> regression tests on solaris/sparc 32 bit: >>>> vm.sysdict.testlist >>>> vm.quick.testlist >>>> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >>>> java.lang.instrument: jtreg >>>> jli with -Xcomp >>>> ctw nightly.testlist >>>> tests in progress on solaris/sparc 32 bit: >>>> runThese -Xcomp >>>> jck vm >>>> >>>> thanks, >>>> Karen >>>> >>>> From jon.masamitsu at oracle.com Thu Jan 10 09:50:14 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 10 Jan 2013 17:50:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20130110175021.5B8D44718C@hg.openjdk.java.net> Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp From vladimir.kozlov at oracle.com Thu Jan 10 12:25:12 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 10 Jan 2013 20:25:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130110202527.BB8A547192@hg.openjdk.java.net> Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.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/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp From zhengyu.gu at oracle.com Thu Jan 10 12:57:08 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 10 Jan 2013 15:57:08 -0500 Subject: Code review request: 8005936,PrintNMTStatistics doesn't work for normal JVM exit Message-ID: <50EF2B24.9030500@oracle.com> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT memory statistics can be reported when PrintNMTStatistics flag is enabled. webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ Tests: 1. JPRT tests 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 and x64 Thanks, -Zhengyu From karen.kinnear at oracle.com Thu Jan 10 13:56:06 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 16:56:06 -0500 Subject: Code review request: 8005936, PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50EF2B24.9030500@oracle.com> References: <50EF2B24.9030500@oracle.com> Message-ID: Zhengyu, This looks good. Thanks for fixing this. I assume you ran your ute tests with the -XX:+PrintNMTStatistics flag on. thanks, Karen On Jan 10, 2013, at 3:57 PM, Zhengyu Gu wrote: > Moved NMT shutdown code to JVM exit handler, so guarantees that NMT memory statistics can be reported when PrintNMTStatistics flag is enabled. > > webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ > > Tests: > > 1. JPRT tests > 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 and x64 > > > Thanks, > > -Zhengyu From zhengyu.gu at oracle.com Thu Jan 10 14:21:46 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 10 Jan 2013 17:21:46 -0500 Subject: Code review request: 8005936,PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: References: <50EF2B24.9030500@oracle.com> Message-ID: <50EF3EFA.8000205@oracle.com> Yes, all with following VM options: -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics Thanks, -Zhengyu On 1/10/2013 4:56 PM, Karen Kinnear wrote: > Zhengyu, > > This looks good. Thanks for fixing this. > I assume you ran your ute tests with the -XX:+PrintNMTStatistics flag on. > > thanks, > Karen > > On Jan 10, 2013, at 3:57 PM, Zhengyu Gu wrote: > >> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT memory statistics can be reported when PrintNMTStatistics flag is enabled. >> >> webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ >> >> Tests: >> >> 1. JPRT tests >> 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 and x64 >> >> >> Thanks, >> >> -Zhengyu From david.holmes at oracle.com Thu Jan 10 14:32:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 08:32:22 +1000 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <1EBA2F30-B362-4668-AF8E-74783E3B3AFB@oracle.com> References: <50ED4992.5000107@oracle.com> <18F4AB83-566D-441C-A0A4-08FBE0E39181@oracle.com> <1EBA2F30-B362-4668-AF8E-74783E3B3AFB@oracle.com> Message-ID: <50EF4176.8020301@oracle.com> Looks good. Thanks Karen. David On 11/01/2013 2:34 AM, Karen Kinnear wrote: > Updated webrev from both David and Coleen's suggestions (many thanks) > > http://cr.openjdk.java.net/~acorn/7199207.postreview/webrev > > Rerunning parallel_class_loading.testlist (which includes circularity testing) and sysdict. > > thanks, > Karen > > On Jan 10, 2013, at 10:52 AM, Karen Kinnear wrote: > >> David, >> >> Good question. I will add an assertion !HAS_PENDING_EXCEPTION before throwing the >> circularity error. And I moved it to right after releasing the lock, which is back to where it >> used to be, so I believe the only risk of a PENDING_EXCEPTION is if you called >> resolve_instance_class_or_null with one already. >> >> So can I count you as a code reviewer? >> >> thanks, >> Karen >> >> On Jan 9, 2013, at 5:42 AM, David Holmes wrote: >> >>> Hi Karen, >>> >>> Can't really comment on the validity or otherwise of the approach but one query: >>> >>> 811 // must throw error outside of owning lock >>> 812 if (throw_circularity_error) { >>> 813 ResourceMark rm(THREAD); >>> 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); >>> 815 } >>> 816 >>> 817 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> 818 return NULL; >>> 819 } >>> >>> Is it the case that we can not have an exception pending if we need to throw the circularity error? If so should we should assert that. Otherwise are we concerned about the exception we will lose? >>> >>> David >>> >>> On 5/01/2013 6:54 AM, Karen Kinnear wrote: >>>> Please review: >>>> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >>>> >>>> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >>>> https://jbs.oracle.com/bugs/browse/JDK-7199207 >>>> >>>> Thanks to Stefan Karlsson for the initial analysis and the test case. >>>> >>>> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >>>> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >>>> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >>>> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >>>> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >>>> >>>> Tests run: >>>> Original test case from bug (linux 32 bit client) >>>> regression tests on solaris/sparc 32 bit: >>>> vm.sysdict.testlist >>>> vm.quick.testlist >>>> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >>>> java.lang.instrument: jtreg >>>> jli with -Xcomp >>>> ctw nightly.testlist >>>> tests in progress on solaris/sparc 32 bit: >>>> runThese -Xcomp >>>> jck vm >>>> >>>> thanks, >>>> Karen >>>> >>>> >> > From karen.kinnear at oracle.com Thu Jan 10 14:49:06 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 17:49:06 -0500 Subject: RFR:7199207 Placeholders cleanup In-Reply-To: <50EF4176.8020301@oracle.com> References: <50ED4992.5000107@oracle.com> <18F4AB83-566D-441C-A0A4-08FBE0E39181@oracle.com> <1EBA2F30-B362-4668-AF8E-74783E3B3AFB@oracle.com> <50EF4176.8020301@oracle.com> Message-ID: <94D083A9-764C-40A7-BBCB-88988559D772@oracle.com> Thanks very much David. thanks, Karen On Jan 10, 2013, at 5:32 PM, David Holmes wrote: > Looks good. > > Thanks Karen. > > David > > On 11/01/2013 2:34 AM, Karen Kinnear wrote: >> Updated webrev from both David and Coleen's suggestions (many thanks) >> >> http://cr.openjdk.java.net/~acorn/7199207.postreview/webrev >> >> Rerunning parallel_class_loading.testlist (which includes circularity testing) and sysdict. >> >> thanks, >> Karen >> >> On Jan 10, 2013, at 10:52 AM, Karen Kinnear wrote: >> >>> David, >>> >>> Good question. I will add an assertion !HAS_PENDING_EXCEPTION before throwing the >>> circularity error. And I moved it to right after releasing the lock, which is back to where it >>> used to be, so I believe the only risk of a PENDING_EXCEPTION is if you called >>> resolve_instance_class_or_null with one already. >>> >>> So can I count you as a code reviewer? >>> >>> thanks, >>> Karen >>> >>> On Jan 9, 2013, at 5:42 AM, David Holmes wrote: >>> >>>> Hi Karen, >>>> >>>> Can't really comment on the validity or otherwise of the approach but one query: >>>> >>>> 811 // must throw error outside of owning lock >>>> 812 if (throw_circularity_error) { >>>> 813 ResourceMark rm(THREAD); >>>> 814 THROW_MSG_0(vmSymbols::java_lang_ClassCircularityError(), name->as_C_string()); >>>> 815 } >>>> 816 >>>> 817 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>> 818 return NULL; >>>> 819 } >>>> >>>> Is it the case that we can not have an exception pending if we need to throw the circularity error? If so should we should assert that. Otherwise are we concerned about the exception we will lose? >>>> >>>> David >>>> >>>> On 5/01/2013 6:54 AM, Karen Kinnear wrote: >>>>> Please review: >>>>> http://cr.openjdk.java.net/~acorn/7199207.fix2merge/webrev/ >>>>> >>>>> bug: NPG: Crash in PlaceholderTable::verify, after a StackOverflow during class loading >>>>> https://jbs.oracle.com/bugs/browse/JDK-7199207 >>>>> >>>>> Thanks to Stefan Karlsson for the initial analysis and the test case. >>>>> >>>>> Thanks to Coleen's suggestion, I've simplified the placeholder table entry cleanup. >>>>> Specifically the placeholder table is not used to keep the instanceKlass alive for GC during class resolution, and no >>>>> other logic depends on the contents of the placeholder table. Therefore rather than retaining the entries for the entire >>>>> span of resolve_from , entries are explicitly added and removed for each specific resolution action: LOAD_INSTANCE, >>>>> LOAD_SUPER and DEFINE_CLASS (used for parallel class loading). >>>>> >>>>> Tests run: >>>>> Original test case from bug (linux 32 bit client) >>>>> regression tests on solaris/sparc 32 bit: >>>>> vm.sysdict.testlist >>>>> vm.quick.testlist >>>>> vm.parallel_class_loading.testlist: no flags, -XX:+AllowParallelDefineClass, -XX:+UnsyncLoadClass, -XX:+PrintSystemDictionaryAtExit >>>>> java.lang.instrument: jtreg >>>>> jli with -Xcomp >>>>> ctw nightly.testlist >>>>> tests in progress on solaris/sparc 32 bit: >>>>> runThese -Xcomp >>>>> jck vm >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> >>> >> From jesper.wilhelmsson at oracle.com Thu Jan 10 15:15:22 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 11 Jan 2013 00:15:22 +0100 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50EEDB43.1050803@oracle.com> References: <50EEDB43.1050803@oracle.com> Message-ID: <50EF4B8A.6050909@oracle.com> Aleksey, I have looked through the change and I don't see anything obviously wrong with it, but this change is in a part of HotSpot that I don't know at all so I wouldn't count this as a review. You are adding a TODO in classFileParser.cpp , is that intentional? I have followed the discussions around @contended over the last year and I feel comfortable sponsoring this change once it has been approved by proper reviewers. /Jesper On 10/1/13 4:16 PM, Aleksey Shipilev wrote: > Hi, > > This is the final call for reviews for @Contended: > http://cr.openjdk.java.net/~shade/8003985/webrev.01/ > > Changes: > - VM: none since latest revision. > - JDK: pruned some Javadocs as requested by CCC reviewers > > Testing: > - (respin to make sure everything still intact) > - Test8003985 passes on Linux x86_64 > - JPRT builds passed > - JPRT testing passed > > Status: > - This change is ready to be pushed > - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) > - CCC is in place, and Approved > > I would need a sponsor to push this. > > Thanks, > Aleksey. From aleksey.shipilev at oracle.com Thu Jan 10 15:20:09 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Jan 2013 03:20:09 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50EF4B8A.6050909@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> Message-ID: <50EF4CA9.6040800@oracle.com> Thanks Jesper! On 01/11/2013 03:15 AM, Jesper Wilhelmsson wrote: > I have looked through the change and I don't see anything obviously > wrong with it, but this change is in a part of HotSpot that I don't know > at all so I wouldn't count this as a review. > > You are adding a TODO in classFileParser.cpp , is that intentional? Yes, we would need to follow up on that once we have more usages, which will allow us to experiment more thoroughly on this. > I have followed the discussions around @contended over the last year and > I feel comfortable sponsoring this change once it has been approved by > proper reviewers. Good. The code was not changed since last review; the only culprit was pending CCC, and now it is approved. I think Vladimir, John, and Coleen were OK. Guys, can you confirm you still OK? -Aleksey. From ioi.lam at oracle.com Thu Jan 10 15:47:37 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Jan 2013 15:47:37 -0800 Subject: RFR: 8005467 CDS size information In-Reply-To: <50EE1440.5080609@oracle.com> References: <50EDB3DA.8010407@oracle.com> <50EDD8A8.7010102@oracle.com> <27BEA167-09B6-4612-9680-6252D1018CC5@oracle.com> <50EE1440.5080609@oracle.com> Message-ID: <50EF5319.6010804@oracle.com> Hi, I have updated the patch to use the formats suggested by Coleen and Christian: http://cr.openjdk.java.net/~coleenp/8005467_cdc_size_info_003/ Now it looks like: ro space: 8687488 [ 40.3% of total] out of 16777216 bytes [51.8% used] at 0x0000000080000000 rw space: 11369872 [ 52.7% of total] out of 16777216 bytes [67.8% used] at 0x0000000081000000 md space: 1487320 [ 6.9% of total] out of 4194304 bytes [35.5% used] at 0x0000000082000000 mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% used] at 0x0000000082400000 total : 21578733 [100.0% of total] out of 37871616 bytes [57.0% used] Thanks - Ioi On 01/09/2013 05:07 PM, Coleen Phillimore wrote: > > How about "used"? GC uses "used" for such things. > > ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] > at 0x0000000080000000. > > Thanks, > Coleen > > On 1/9/2013 5:29 PM, Christian Thalinger wrote: >> On Jan 9, 2013, at 12:52 PM, Ioi Lam wrote: >> >>> On 01/09/2013 12:20 PM, Christian Thalinger wrote: >>>> On Jan 9, 2013, at 10:15 AM, Ioi Lam wrote: >>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ >>>>> >>>>> bug: CDS size information is incorrect and unfriendly >>>>> https://jbs.oracle.com/bugs/browse/JDK-8005467 >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The printed size information is changed from >>>>> >>>>> ro space: 0x000000000014718a out of 0x0000000000200000 words >>>>> allocated at 0x0000000080000000. >>>>> rw space: 0x000000000017a6ac out of 0x0000000000200000 words >>>>> allocated at 0x0000000081000000. >>>>> md space: 0x0000000000241a70 out of 0x0000000000400000 words >>>>> allocated at 0x0000000082000000. >>>>> mc space: 0x0000000000008505 out of 0x000000000001e000 words >>>>> allocated at 0x0000000082400000. >>>>> >>>>> to >>>>> >>>>> ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% >>>>> full] at 0x0000000080000000. >>>>> rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% >>>>> full] at 0x0000000081000000. >>>>> md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% >>>>> full] at 0x0000000082000000. >>>>> mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% >>>>> full] at 0x0000000082400000. >>>> The "% total" and "% full" are confusing. Should this be "% of >>>> total"? >>>> >>>>> total : 21178485 bytes >>>> This is "total usage", I suppose. Could we also print "total >>>> allocated size"? >>> Hi Chris, >>> >>> Thanks for the review. Would this be clearer? >>> >>> ro space: 8287312 [ 39.1% of total] out of 16777216 bytes [49.4% >>> occupied] at 0x0000000080000000 >>> rw space: 11369872 [ 53.7% of total] out of 16777216 bytes [67.8% >>> occupied] at 0x0000000081000000 >>> md space: 1487248 [ 7.0% of total] out of 4194304 bytes [35.5% >>> occupied] at 0x0000000082000000 >>> mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% >>> occupied] at 0x0000000082400000 >>> total : 21178485 [100.0% of total] out of 37871616 bytes [55.9% >>> occupied] >> Much better. Thanks. -- Chris >> >>> >>> Thanks >>> - Ioi >>> >>>> -- Chris >>>> >>>>> There is otherwise no functional change. >>>>> >>>>> >>>>> Tests run: >>>>> >>>>> + JPRT -- to verify build-ability >>>>> >>>>> + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 >>>>> (32- and 64-bit VM) to verify the printed output is as expected. >>>>> >>>>> Thanks, >>>>> Ioi >>>>> > From vitalyd at gmail.com Thu Jan 10 16:29:45 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 10 Jan 2013 19:29:45 -0500 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50EF4CA9.6040800@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> Message-ID: Hi Aleksey, Just a side comment - why not query the OS to get the cache line size right from the get go instead of postponing it to a future change? Linux and windows have APIs to get it fairly easily, and I'm guessing Solaris and others do as well Thanks Sent from my phone On Jan 10, 2013 6:20 PM, "Aleksey Shipilev" wrote: > Thanks Jesper! > > On 01/11/2013 03:15 AM, Jesper Wilhelmsson wrote: > > I have looked through the change and I don't see anything obviously > > wrong with it, but this change is in a part of HotSpot that I don't know > > at all so I wouldn't count this as a review. > > > > You are adding a TODO in classFileParser.cpp , is that intentional? > > Yes, we would need to follow up on that once we have more usages, which > will allow us to experiment more thoroughly on this. > > > I have followed the discussions around @contended over the last year and > > I feel comfortable sponsoring this change once it has been approved by > > proper reviewers. > > Good. The code was not changed since last review; the only culprit was > pending CCC, and now it is approved. I think Vladimir, John, and Coleen > were OK. Guys, can you confirm you still OK? > > -Aleksey. > From vladimir.kozlov at oracle.com Thu Jan 10 18:48:46 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Jan 2013 02:48:46 +0000 Subject: hg: hsx/hsx24/hotspot: 17 new changesets Message-ID: <20130111024928.A2F12471B7@hg.openjdk.java.net> Changeset: 57adf5774d20 Author: bharadwaj Date: 2012-11-15 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/57adf5774d20 8001077: remove ciMethod::will_link Summary: Removed will_link and changed all calls to is_loaded(). Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/doCall.cpp Changeset: decd75a744ee Author: kvn Date: 2012-11-16 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/decd75a744ee 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Summary: Increase the stack size in the run parameters. Reviewed-by: kvn Contributed-by: david.r.chase at oracle.com ! test/compiler/6865265/StackOverflowBug.java Changeset: 0245298c87e3 Author: vlivanov Date: 2012-11-21 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0245298c87e3 8001538: hs_err file does not list anymore compiled methods in compilation events Summary: Fixed message buffer size calculation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/utilities/events.hpp Changeset: dedce7e602e1 Author: twisti Date: 2012-11-26 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dedce7e602e1 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.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/locknode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/type.hpp Changeset: 733356efcc6e Author: bharadwaj Date: 2012-11-27 17:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/733356efcc6e 7092905: C2: Keep track of the number of dead nodes Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes. Reviewed-by: kvn, twisti, jrose, vlivanov ! src/share/tools/LogCompilation/README ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/stringopts.cpp Changeset: d075d420d60e Author: twisti Date: 2012-12-03 15:48 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d075d420d60e 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Reviewed-by: kvn, johnc ! src/share/vm/opto/library_call.cpp Changeset: 9180a0168de8 Author: neliasso Date: 2012-11-26 15:11 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9180a0168de8 8003983: LogCompilation tool is broken since c1 support Summary: Fixed emitting and parsing Reviewed-by: jrose, kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: 3b5a0977ab9f Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b5a0977ab9f 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: e396285cea04 Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e396285cea04 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! 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/library_call.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 7dedd32ceb2f Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7dedd32ceb2f 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 9e7f63123dfe Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9e7f63123dfe 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java Changeset: d653d418e54c Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d653d418e54c 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java Changeset: 841d6285ff8a Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/841d6285ff8a 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java Changeset: 2f169876df42 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2f169876df42 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.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/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 1da9509ab853 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1da9509ab853 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: 1b08add4c387 Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1b08add4c387 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 0deee949d657 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0deee949d657 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + test/compiler/8005419/Test8005419.java From john.coomes at oracle.com Thu Jan 10 20:31:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:31:38 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b72 for changeset c1be681d80a1 Message-ID: <20130111043138.A3F8C471BC@hg.openjdk.java.net> Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:31:42 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:31:42 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b72 for changeset cb40427f4714 Message-ID: <20130111043145.80B55471BD@hg.openjdk.java.net> Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:31:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:31:49 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b72 for changeset bdf2af722a6b Message-ID: <20130111043158.B6CEC471BE@hg.openjdk.java.net> Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:32:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:32:03 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b72 for changeset d9707230294d Message-ID: <20130111043208.9EC45471BF@hg.openjdk.java.net> Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:32:17 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:32:17 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b72 for changeset 32a57e645e01 Message-ID: <20130111043314.17958471C0@hg.openjdk.java.net> Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:34:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:34:20 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b72 for changeset 6f0986ed9b7e Message-ID: <20130111043429.86573471C1@hg.openjdk.java.net> Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags From david.holmes at oracle.com Thu Jan 10 21:04:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 15:04:39 +1000 Subject: Code review request: 8005936,PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50EF2B24.9030500@oracle.com> References: <50EF2B24.9030500@oracle.com> Message-ID: <50EF9D67.8000806@oracle.com> On 11/01/2013 6:57 AM, Zhengyu Gu wrote: > Moved NMT shutdown code to JVM exit handler, so guarantees that NMT > memory statistics can be reported when PrintNMTStatistics flag is enabled. > > webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ print_statistics() seems the wrong place to put the shutdown code. Plus you only added it to the non-product path. David > Tests: > > 1. JPRT tests > 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 and x64 > > > Thanks, > > -Zhengyu From jiangli.zhou at oracle.com Thu Jan 10 22:15:57 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Fri, 11 Jan 2013 06:15:57 +0000 Subject: hg: hsx/hsx24/hotspot: 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9. Message-ID: <20130111061607.F403D471DF@hg.openjdk.java.net> Changeset: 0e25216625f7 Author: jiangli Date: 2013-01-10 23:03 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0e25216625f7 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp From aleksey.shipilev at oracle.com Fri Jan 11 00:05:04 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Jan 2013 12:05:04 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> Message-ID: <50EFC7B0.1000205@oracle.com> On 01/11/2013 04:29 AM, Vitaly Davidovich wrote: > Just a side comment - why not query the OS to get the cache line size > right from the get go instead of postponing it to a future change? Linux > and windows have APIs to get it fairly easily, and I'm guessing Solaris > and others do as well The issue is not about querying cache line size (that one is easy), but the interactions with hardware prefetchers which need to be researched on. -Aleksey. From alejandro.murillo at oracle.com Fri Jan 11 04:06:18 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 11 Jan 2013 12:06:18 +0000 Subject: hg: hsx/hsx25/hotspot: 42 new changesets Message-ID: <20130111120743.A2F18471E3@hg.openjdk.java.net> Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! 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/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/608b2e8a0063 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: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.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/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags From vitalyd at gmail.com Fri Jan 11 05:14:31 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Jan 2013 08:14:31 -0500 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50EFC7B0.1000205@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50EFC7B0.1000205@oracle.com> Message-ID: What interaction with the prefetcher are you concerned about? I still think it would be better to get line size from OS (or CPU) rather than hardcoding a default - this seems orthogonal to the prefetcher issue since the default you picked is probably going to be either the same size or larger than what os/CPU would've reported. Thanks Sent from my phone On Jan 11, 2013 3:05 AM, "Aleksey Shipilev" wrote: > On 01/11/2013 04:29 AM, Vitaly Davidovich wrote: > > Just a side comment - why not query the OS to get the cache line size > > right from the get go instead of postponing it to a future change? Linux > > and windows have APIs to get it fairly easily, and I'm guessing Solaris > > and others do as well > > The issue is not about querying cache line size (that one is easy), but > the interactions with hardware prefetchers which need to be researched on. > > -Aleksey. > > From karen.kinnear at oracle.com Fri Jan 11 05:15:08 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 11 Jan 2013 08:15:08 -0500 Subject: Code review request: 8005936, PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50EF9D67.8000806@oracle.com> References: <50EF2B24.9030500@oracle.com> <50EF9D67.8000806@oracle.com> Message-ID: <54F49864-8485-4C0B-9069-5789A3D802AE@oracle.com> Good catch David. Zhengyu - looks like you could put this right after the call to print_statistics in before_exit in java.cpp. thanks, KAren On Jan 11, 2013, at 12:04 AM, David Holmes wrote: > On 11/01/2013 6:57 AM, Zhengyu Gu wrote: >> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT >> memory statistics can be reported when PrintNMTStatistics flag is enabled. >> >> webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ > > print_statistics() seems the wrong place to put the shutdown code. Plus you only added it to the non-product path. > > David > >> Tests: >> >> 1. JPRT tests >> 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 and x64 >> >> >> Thanks, >> >> -Zhengyu From joel.franck at oracle.com Fri Jan 11 05:42:00 2013 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 11 Jan 2013 14:42:00 +0100 Subject: RFR: 8004823: Add VM support for type annotation reflection In-Reply-To: <50EDED4F.90609@oracle.com> References: <50D0A247.20502@oracle.com> <8A89B42E-3357-4085-9EAC-62CDA90792EB@oracle.com> <50EDED4F.90609@oracle.com> Message-ID: <50F016A8.1030806@oracle.com> Hi Ioi, Good catch! I agree the checks should be added to all method_* annotation arrays. Most of the classes loaded for Hello world should not only have a null type_annotations, but also a null annotations from instanceKlass. I don't think that will ever happen as is. I can fix this but I doubt I have the time before M6. If you have the time please feel free to fix this :) cheers /Joel On 01/09/2013 11:21 PM, Ioi Lam wrote: > Hi Joel, > > I found a possible issue with the new type annotation code (changset > 35431a769282). Should this extra NULL check be added? > > diff -r 36171820ba15 src/share/vm/classfile/classFileParser.cpp > --- a/src/share/vm/classfile/classFileParser.cpp Mon Jan 07 13:10:37 2013 > -0800 > +++ b/src/share/vm/classfile/classFileParser.cpp Wed Jan 09 13:48:39 2013 > -0800 > @@ -2467,11 +2467,13 @@ > MetadataFactory::new_array(loader_data, length, NULL, > CHECK_NULL); > } > (*methods_default_annotations)->at_put(index, > method_default_annotations); > *+ if (method_type_annotations != NULL) {** > * if (*methods_type_annotations == NULL) { > *methods_type_annotations = > MetadataFactory::new_array(loader_data, length, NULL, > CHECK_NULL); > } > (*methods_type_annotations)->at_put(index, method_type_annotations); > *+ }** > * } > > I am testing a HelloWorld program and all loaded classes (all of them from > rt.jar) have a non-zero Annotations::type_annotation() field (all added up > to about 64KB of data for about 400 loaded classes). > > After my patch above, the type_annotations take up zero bytes. > > Actually, the more I look at this block of code, it seems like a similar > check should be done for methods_annotations, methods_parameter_annotations > and methods_default_annotations as well (in classFileParser.cpp, just above > the code quoted above). > > If we can avoid the allocation of these annotations arrays, for Eclipse, we > can save about 4.2MB of allocations (with about 9000 loaded classes) on > Linux/x64. > > Thanks > - Ioi > > > On 12/27/2012 04:57 AM, Joel Borggr?n-Franck wrote: >> Thanks for the review John! >> >> I had this pushed before I saw this. I'll make sure to implement the checks when I start to implement retransform for type annotations in the VM. >> >> cheers >> /Joel >> >> On Dec 20, 2012, at 10:10 PM, John Rose wrote: >> >>> This is good work. You can count me as a reviewer. >>> >>> One comment: There are a couple of places where a field index is used as an annotation array index (one old one new). I think it would be best to put an explicit range check like this: >>> >>> - if (md == NULL) >>> + if (md == NULL || index() >= md->length()) >>> return NULL; >>> return md->at(index()); >>> >>> There are two reasons: First, although it is likely this is a needless check, the code which ensures length equality for field arrays and annotation arrays is buried in another file (classFileParser) and hard to check. Second, recent changes to classFileParser actually decouple the field array length from the value declared in the class file, by injecting extra fields into certain system classes. Although it is (again) unlikely that this will cause a problem, putting a local range check in the code above guarantees an adequate level of safety. >>> >>> The "at" method includes an assertion check, which is also good, but assertions are (a) not enabled in product mode and (b) can crash the VM if they fail. >>> >>> ? John >>> >>> On Dec 18, 2012, at 9:05 AM, Joel Borggr?n-Franck wrote: >>> >>>> New webrev up: >>>> >>>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/ >>>> >>>> - I had to rename the field name for the type annotation byte[] in Field, Constructor and Method. >>>> >>>> Also fixed: >>>> >>>> - I fixed the mapfile that got reindented. >>>> - Added back a comment that I accidentally removed. > From alejandro.murillo at oracle.com Fri Jan 11 05:59:31 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 11 Jan 2013 13:59:31 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20130111135954.0991F471E9@hg.openjdk.java.net> Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version From zhengyu.gu at oracle.com Fri Jan 11 07:18:01 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 11 Jan 2013 10:18:01 -0500 Subject: Code review request: 8005936,PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50EF9D67.8000806@oracle.com> References: <50EF2B24.9030500@oracle.com> <50EF9D67.8000806@oracle.com> Message-ID: <50F02D29.30608@oracle.com> Thanks, David. My bad, I do mean JVM exit handler, but rushed ... Here is updated webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.01/ Thanks, -Zhengyu On 1/11/2013 12:04 AM, David Holmes wrote: > On 11/01/2013 6:57 AM, Zhengyu Gu wrote: >> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT >> memory statistics can be reported when PrintNMTStatistics flag is >> enabled. >> >> webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ > > print_statistics() seems the wrong place to put the shutdown code. > Plus you only added it to the non-product path. > > David > >> Tests: >> >> 1. JPRT tests >> 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 >> and x64 >> >> >> Thanks, >> >> -Zhengyu From coleen.phillimore at oracle.com Fri Jan 11 08:48:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Jan 2013 11:48:02 -0500 Subject: Code review request: 8005936,PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50F02D29.30608@oracle.com> References: <50EF2B24.9030500@oracle.com> <50EF9D67.8000806@oracle.com> <50F02D29.30608@oracle.com> Message-ID: <50F04242.30902@oracle.com> This looks good to me. Coleen On 1/11/2013 10:18 AM, Zhengyu Gu wrote: > Thanks, David. > > My bad, I do mean JVM exit handler, but rushed ... > Here is updated webrev: > > http://cr.openjdk.java.net/~zgu/8005936/webrev.01/ > > Thanks, > > -Zhengyu > > On 1/11/2013 12:04 AM, David Holmes wrote: >> On 11/01/2013 6:57 AM, Zhengyu Gu wrote: >>> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT >>> memory statistics can be reported when PrintNMTStatistics flag is >>> enabled. >>> >>> webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ >> >> print_statistics() seems the wrong place to put the shutdown code. >> Plus you only added it to the non-product path. >> >> David >> >>> Tests: >>> >>> 1. JPRT tests >>> 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 >>> and x64 >>> >>> >>> Thanks, >>> >>> -Zhengyu From gnu.andrew at redhat.com Fri Jan 11 09:29:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Jan 2013 12:29:21 -0500 (EST) Subject: HotSpot Changes in 7u In-Reply-To: <50D3C26E.3040900@oracle.com> Message-ID: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> ----- Original Message ----- > On 21/12/2012 9:51 AM, Coleen Phillimore wrote: > > > > I am checking these changes into hsx24 now. > > Thanks Coleen. > Yes, thanks Coleen for taking this on. I see they've now appeared in 7u/hotspot. http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9d98c1eb82b0 Any chance of getting: 8000780: make Zero build and run with JDK8 http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5 in too? Or is it not appropriate? CCing the original reviewers & author. -- 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 coleen.phillimore at oracle.com Fri Jan 11 10:32:21 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Jan 2013 13:32:21 -0500 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50EEDB43.1050803@oracle.com> References: <50EEDB43.1050803@oracle.com> Message-ID: <50F05AB5.2030106@oracle.com> Aleksey, The hotspot changes look fine. It appears to me that you've done the necessary work to get it funded and approved. Thanks, Coleen On 1/10/2013 10:16 AM, Aleksey Shipilev wrote: > Hi, > > This is the final call for reviews for @Contended: > http://cr.openjdk.java.net/~shade/8003985/webrev.01/ > > Changes: > - VM: none since latest revision. > - JDK: pruned some Javadocs as requested by CCC reviewers > > Testing: > - (respin to make sure everything still intact) > - Test8003985 passes on Linux x86_64 > - JPRT builds passed > - JPRT testing passed > > Status: > - This change is ready to be pushed > - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) > - CCC is in place, and Approved > > I would need a sponsor to push this. > > Thanks, > Aleksey. From ChrisPhi at LGonQn.Org Fri Jan 11 11:08:34 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Fri, 11 Jan 2013 14:08:34 -0500 Subject: HotSpot Changes in 7u In-Reply-To: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> References: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> Message-ID: <50F06332.9000805@LGonQn.Org> Hi On 11/01/13 12:29 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 21/12/2012 9:51 AM, Coleen Phillimore wrote: >>> I am checking these changes into hsx24 now. >> Thanks Coleen. >> > Yes, thanks Coleen for taking this on. I see they've now appeared in 7u/hotspot. > > http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71 > http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9d98c1eb82b0 > > Any chance of getting: > > 8000780: make Zero build and run with JDK8 > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5 This required a backport that has been reviewed by Roman and Christian (Thanks!). See attached email's from Alejandro and Christian. > > in too? Or is it not appropriate? > > CCing the original reviewers & author. > Chris -------------- next part -------------- An embedded message was scrubbed... From: Alejandro E Murillo Subject: Re: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] Date: Sat, 22 Dec 2012 11:27:57 -0700 Size: 5546 Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130111/3eb5443e/AttachedMessage.nws -------------- next part -------------- An embedded message was scrubbed... From: Christian Thalinger Subject: Re: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] Date: Wed, 2 Jan 2013 12:02:10 -0800 Size: 4205 Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130111/3eb5443e/AttachedMessage-0001.nws From vladimir.kozlov at oracle.com Fri Jan 11 11:34:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 11:34:59 -0800 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50EF4CA9.6040800@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> Message-ID: <50F06963.7070809@oracle.com> Aleksey, Please, file separate bug for jdk changes, create separate webrev and send it to core-libs-dev at openjdk.java.net for review (CC to hotspot-dev). And do it for future changes which involve jdk changes. I did not look on this code before, I think. You can set ContendedPaddingWidth lower and redefine it in vm_version_.cpp: if (cache_line_size > ContendedPaddingWidth) ContendedPaddingWidth = cache_line_size; On other hand 128 value is very conservative and should satisfy all current platform VM run on. But you will wast java heap space. There is no explanation in code what contending groups are. The only comment I see: + if (fs.contended_group() == 0) { + // special case, this default group is padded within Why other groups don't need padding between fields? Also why you padding after fields again? You did padding before fields already? You can wasting space at the end of object or in between super and subclass fields. In vmSymbols.hpp Contended signature should not be in "error klasses" group. Separate it by comment. In the test change copyright year to 2013. Also @summary should be bug's "Support Contended Annotation - JEP 142" Thanks, Vladimir On 1/10/13 3:20 PM, Aleksey Shipilev wrote: > Thanks Jesper! > > On 01/11/2013 03:15 AM, Jesper Wilhelmsson wrote: >> I have looked through the change and I don't see anything obviously >> wrong with it, but this change is in a part of HotSpot that I don't know >> at all so I wouldn't count this as a review. >> >> You are adding a TODO in classFileParser.cpp , is that intentional? > > Yes, we would need to follow up on that once we have more usages, which > will allow us to experiment more thoroughly on this. > >> I have followed the discussions around @contended over the last year and >> I feel comfortable sponsoring this change once it has been approved by >> proper reviewers. > > Good. The code was not changed since last review; the only culprit was > pending CCC, and now it is approved. I think Vladimir, John, and Coleen > were OK. Guys, can you confirm you still OK? > > -Aleksey. > From alejandro.murillo at oracle.com Fri Jan 11 12:52:16 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 11 Jan 2013 20:52:16 +0000 Subject: hg: hsx/hsx24/hotspot: 23 new changesets Message-ID: <20130111205303.93E7847208@hg.openjdk.java.net> Changeset: 6c264aad54e4 Author: katleman Date: 2012-12-27 14:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6c264aad54e4 Added tag jdk7u12-b07 for changeset 4f7ad6299356 ! .hgtags Changeset: d2e25680db9d Author: amurillo Date: 2012-10-01 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d2e25680db9d 7198640: new hotspot build - hs23.6-b04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d37fd995683a Author: katleman Date: 2012-10-03 17:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d37fd995683a Added tag jdk7u10-b10 for changeset d2e25680db9d ! .hgtags Changeset: f26f3d92e6d9 Author: katleman Date: 2012-10-10 18:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f26f3d92e6d9 Added tag jdk7u10-b11 for changeset d37fd995683a ! .hgtags Changeset: 58881c615a51 Author: katleman Date: 2012-10-17 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/58881c615a51 Added tag jdk7u10-b12 for changeset f26f3d92e6d9 ! .hgtags Changeset: cdbf4d442b56 Author: katleman Date: 2012-10-24 12:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cdbf4d442b56 Added tag jdk7u10-b13 for changeset 58881c615a51 ! .hgtags Changeset: 0df1563b8283 Author: katleman Date: 2012-10-31 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0df1563b8283 Added tag jdk7u10-b14 for changeset cdbf4d442b56 ! .hgtags Changeset: f3f34d00d977 Author: kevinw Date: 2012-04-20 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f3f34d00d977 7162488: VM not printing unknown -XX options Reviewed-by: dholmes, kamg ! src/share/vm/runtime/arguments.cpp + test/runtime/7162488/Test7162488.sh Changeset: 63e8b49b329e Author: lana Date: 2012-11-06 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/63e8b49b329e Merge Changeset: 1cb34ef50bdd Author: katleman Date: 2012-11-07 17:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1cb34ef50bdd Added tag jdk7u10-b15 for changeset 63e8b49b329e ! .hgtags Changeset: 5c154a591de9 Author: katleman Date: 2012-11-14 18:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5c154a591de9 Added tag jdk7u10-b16 for changeset 1cb34ef50bdd ! .hgtags Changeset: 78c7e1b4a006 Author: cl Date: 2012-11-21 21:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/78c7e1b4a006 Added tag jdk7u10-b17 for changeset 5c154a591de9 ! .hgtags Changeset: c6b78bbaf697 Author: katleman Date: 2012-11-28 15:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c6b78bbaf697 Added tag jdk7u10-b18 for changeset 78c7e1b4a006 ! .hgtags Changeset: 25a92b94ad53 Author: katleman Date: 2012-12-04 17:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/25a92b94ad53 Added tag jdk7u10-b30 for changeset c6b78bbaf697 ! .hgtags Changeset: 0faacf491ae3 Author: coffeys Date: 2012-12-18 12:30 +0000 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0faacf491ae3 Merge ! .hgtags ! make/hotspot_version ! src/share/vm/runtime/arguments.cpp Changeset: c946de7cd39c Author: coffeys Date: 2012-12-20 12:11 +0000 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c946de7cd39c Merge ! .hgtags ! make/hotspot_version Changeset: b35e8ba33d75 Author: amurillo Date: 2012-12-26 04:00 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b35e8ba33d75 Merge ! .hgtags Changeset: 38629edadb15 Author: amurillo Date: 2012-12-26 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/38629edadb15 Merge ! .hgtags ! make/hotspot_version Changeset: 3bb803664f3d Author: lana Date: 2012-12-28 10:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3bb803664f3d Merge ! .hgtags Changeset: 92e382c3cccc Author: katleman Date: 2013-01-03 13:21 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/92e382c3cccc Added tag jdk7u12-b08 for changeset 3bb803664f3d ! .hgtags Changeset: 0d5d62e38450 Author: katleman Date: 2013-01-09 20:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0d5d62e38450 Added tag jdk7u12-b09 for changeset 92e382c3cccc ! .hgtags Changeset: 7554f9b2bcc7 Author: amurillo Date: 2013-01-11 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7554f9b2bcc7 Merge ! make/hotspot_version ! src/share/vm/runtime/arguments.cpp Changeset: 181528fd1e74 Author: amurillo Date: 2013-01-11 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/181528fd1e74 Added tag hs24-b29 for changeset 7554f9b2bcc7 ! .hgtags From aleksey.shipilev at oracle.com Fri Jan 11 13:00:50 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 01:00:50 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F06963.7070809@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> Message-ID: <50F07D82.1050105@oracle.com> On 01/11/2013 11:34 PM, Vladimir Kozlov wrote: > Please, file separate bug for jdk changes, create separate webrev and > send it to core-libs-dev at openjdk.java.net for review (CC to > hotspot-dev). And do it for future changes which involve jdk changes. (passive-aggressive mode on) Sorry, but this is very unsettling to hear on 10-th review cycle. Up until now I carefully jumped through the hoops of maintainers' opinions, but at this point my patience at all time low level. Anything else you guys have up your sleeve saved for the next round of reviews? Will that "new" CR require the new spin of CCC... because, technically, that would be another CR, not the one CCC decision is acted upon? Will it be more convenient to dump the annotation stub from HotSpot change at all (which also throws away the jtreg test), and wait for this annotation to ship from regular jsr166 channel? Please consider pushing this change in it's current form. This is needed for JDK8 concurrency work, and we can't really miss the integration deadline because of the cosmetic issues. (passive-aggressive mode off) Now to the comments: > You can set ContendedPaddingWidth lower and redefine it in > vm_version_.cpp: > > if (cache_line_size > ContendedPaddingWidth) > ContendedPaddingWidth = cache_line_size; Beefing up ContendedPaddingWidth when larger cache line was detected is fine. But, will user setting be favored this way? I would like to be able to set it lower than the cache line size for perf testing. > On other hand 128 value is very conservative and should satisfy all > current platform VM run on. But you will wast java heap space. We can live with pessimistic value. That's the price we pay for dodging false sharing on the platforms with hardware prefetchers turned on. > There is no explanation in code what contending groups are. The only > comment I see: > > + if (fs.contended_group() == 0) { > + // special case, this default group is padded within > > Why other groups don't need padding between fields? That is by the definition of contended group. Contended group defines the equivalence class over the fields: the fields within the same contended group are not inter-padded. The only exception is default group, which does not incur the equivalence, and so requires intra-padding. I tempted not to go in the detail in HotSpot code, because that is (to be) explained in the @Contended Javadoc: http://gee.cs.oswego.edu/dl/jsr166/src/dl/sun/misc/sun/misc/Contended.html (which is, but the weird legalese reason, can not be committed in OpenJDK first, and then pushed to jsr166). > Also why you padding after fields again? You did padding before fields > already? You can wasting space at the end of object or in between super > and subclass fields. Yes, and that is expected: the padding in the end saves us from false sharing against either subclass fields, or the header/fields of adjacent object. The adjacent object can be unpadded (generally we don't even know what that object is). > In vmSymbols.hpp Contended signature should not be in "error klasses" > group. Separate it by comment. Cosmetics; can be updated before the push. > In the test change copyright year to 2013. Also @summary should be bug's > "Support Contended Annotation - JEP 142" Ditto. Cosmetics; can be updated before the push. -Aleksey. From joe.darcy at oracle.com Fri Jan 11 13:12:25 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jan 2013 13:12:25 -0800 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F07D82.1050105@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> Message-ID: <50F08039.3020505@oracle.com> On 1/11/2013 1:00 PM, Aleksey Shipilev wrote: > On 01/11/2013 11:34 PM, Vladimir Kozlov wrote: >> Please, file separate bug for jdk changes, create separate webrev and >> send it to core-libs-dev at openjdk.java.net for review (CC to >> hotspot-dev). And do it for future changes which involve jdk changes. > (passive-aggressive mode on) > > Sorry, but this is very unsettling to hear on 10-th review cycle. Up > until now I carefully jumped through the hoops of maintainers' opinions, > but at this point my patience at all time low level. Anything else you > guys have up your sleeve saved for the next round of reviews? > > Will that "new" CR require the new spin of CCC... because, technically, > that would be another CR, not the one CCC decision is acted upon? Will > it be more convenient to dump the annotation stub from HotSpot change at > all (which also throws away the jtreg test), and wait for this > annotation to ship from regular jsr166 channel? It is marginally acceptable to use the same bug id to push to different *repos*. For example, the same bug id can be used to push into hotspot and jdk. This has been done before many times and is okay with respect to jcheck. If you want a separate bug id, create a subtask of 8003985 in JIRA to "push @Contended into jdk repo." The ccc does *not* want to see the same version of this work resubmitted under a new bugid. Cheers, -Joe > > Please consider pushing this change in it's current form. This is needed > for JDK8 concurrency work, and we can't really miss the integration > deadline because of the cosmetic issues. > > (passive-aggressive mode off) > > Now to the comments: > >> You can set ContendedPaddingWidth lower and redefine it in >> vm_version_.cpp: >> >> if (cache_line_size > ContendedPaddingWidth) >> ContendedPaddingWidth = cache_line_size; > Beefing up ContendedPaddingWidth when larger cache line was detected is > fine. But, will user setting be favored this way? I would like to be > able to set it lower than the cache line size for perf testing. > >> On other hand 128 value is very conservative and should satisfy all >> current platform VM run on. But you will wast java heap space. > We can live with pessimistic value. That's the price we pay for dodging > false sharing on the platforms with hardware prefetchers turned on. > >> There is no explanation in code what contending groups are. The only >> comment I see: >> >> + if (fs.contended_group() == 0) { >> + // special case, this default group is padded within >> >> Why other groups don't need padding between fields? > That is by the definition of contended group. Contended group defines > the equivalence class over the fields: the fields within the same > contended group are not inter-padded. The only exception is default > group, which does not incur the equivalence, and so requires > intra-padding. I tempted not to go in the detail in HotSpot code, > because that is (to be) explained in the @Contended Javadoc: > http://gee.cs.oswego.edu/dl/jsr166/src/dl/sun/misc/sun/misc/Contended.html > (which is, but the weird legalese reason, can not be committed in > OpenJDK first, and then pushed to jsr166). > >> Also why you padding after fields again? You did padding before fields >> already? You can wasting space at the end of object or in between super >> and subclass fields. > Yes, and that is expected: the padding in the end saves us from false > sharing against either subclass fields, or the header/fields of adjacent > object. The adjacent object can be unpadded (generally we don't even > know what that object is). > >> In vmSymbols.hpp Contended signature should not be in "error klasses" >> group. Separate it by comment. > Cosmetics; can be updated before the push. > >> In the test change copyright year to 2013. Also @summary should be bug's >> "Support Contended Annotation - JEP 142" > Ditto. Cosmetics; can be updated before the push. > > -Aleksey. From aleksey.shipilev at oracle.com Fri Jan 11 13:38:52 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 01:38:52 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50EFC7B0.1000205@oracle.com> Message-ID: <50F0866C.6030000@oracle.com> On 01/11/2013 05:14 PM, Vitaly Davidovich wrote: > What interaction with the prefetcher are you concerned about? We are going in circles on this. Adjacent cache line prefetchers acquire the ownership for the consecutive cache line. That makes the padding with single cache line not sufficient, and requires at least two. There's no clear way to deal with this, and so we bail out at this point for the pessimistic estimate. > I still think it would be better to get line size from OS (or CPU) > rather than hardcoding a default - this seems orthogonal to the > prefetcher issue since the default you picked is probably going to be > either the same size or larger than what os/CPU would've reported. This is an interesting debate, and, again, I don't want to have it in the course of this changeset. This debate requires research. This debate requires experiments. This debate requires running on multitude of platforms. Not to mention that the code messing with MSRs trying to figure out the absence of hardware prefetchers on all CPUs is comparable in size with the classloader changes in this patch. We know pessimistic estimate works in all cases we care about. Please let the *infrastructure code* to be committed into mainline to actually *enable* us to do further research. When jsr166 code migrates to use @Contended, you will have the perfect testbed to drive the "let's optimize @Contended footprint" rally, when you will have the performance tests backing up that work. -Aleksey. P.S. I'm continuously surprised on people wanting to fix everything at once. Argh. From dl at cs.oswego.edu Fri Jan 11 13:49:31 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 11 Jan 2013 16:49:31 -0500 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0866C.6030000@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50EFC7B0.1000205@oracle.com> <50F0866C.6030000@oracle.com> Message-ID: <50F088EB.3030004@cs.oswego.edu> > On 01/11/2013 05:14 PM, Vitaly Davidovich wrote: >> I still think it would be better to get line size from OS (or CPU) >> rather than hardcoding a default - this seems orthogonal to the >> prefetcher issue since the default you picked is probably going to be >> either the same size or larger than what os/CPU would've reported. In case it helps resolve this a bit: The logistic problem is that we do not know a way to reliably compute the effective cacheline length given the possibility (and these days, likelihood) of adjacent prefetching or other memory system quirks. And unreliable detection is worse than no detection. So, in the near term, the only course of action is to set this up using reasonable defaults, and improve them over time. Which is what Aleksey did. -Doug From vladimir.kozlov at oracle.com Fri Jan 11 14:10:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 14:10:22 -0800 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F07D82.1050105@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> Message-ID: <50F08DCE.1060907@oracle.com> On 1/11/13 1:00 PM, Aleksey Shipilev wrote: > On 01/11/2013 11:34 PM, Vladimir Kozlov wrote: >> Please, file separate bug for jdk changes, create separate webrev and >> send it to core-libs-dev at openjdk.java.net for review (CC to >> hotspot-dev). And do it for future changes which involve jdk changes. > > (passive-aggressive mode on) > > Sorry, but this is very unsettling to hear on 10-th review cycle. Up > until now I carefully jumped through the hoops of maintainers' opinions, > but at this point my patience at all time low level. Anything else you > guys have up your sleeve saved for the next round of reviews? (passive-aggressive mode on) I mentioned this because for previous your changes "8004330: Add missing Unsafe entry points" I had to do it for you. You should make life of your sponsor better and not worse, we have a lot of other things to do. (passive-aggressive mode off) > > Will that "new" CR require the new spin of CCC... because, technically, > that would be another CR, not the one CCC decision is acted upon? Will > it be more convenient to dump the annotation stub from HotSpot change at > all (which also throws away the jtreg test), and wait for this > annotation to ship from regular jsr166 channel? As Joe responded we can use the same bug id or create subCR. I rises this question because of long conversation thread this week about jdk changes for, again, 8004330 when library guys did not know what happened with the changes. > > Please consider pushing this change in it's current form. This is needed > for JDK8 concurrency work, and we can't really miss the integration > deadline because of the cosmetic issues. > > (passive-aggressive mode off) > > Now to the comments: > >> You can set ContendedPaddingWidth lower and redefine it in >> vm_version_.cpp: >> >> if (cache_line_size > ContendedPaddingWidth) >> ContendedPaddingWidth = cache_line_size; > > Beefing up ContendedPaddingWidth when larger cache line was detected is > fine. But, will user setting be favored this way? I would like to be > able to set it lower than the cache line size for perf testing. You can accomplish this with: if (FLAG_IS_DEFAULT(ContendedPaddingWidth) && (cache_line_size > ContendedPaddingWidth)) ContendedPaddingWidth = cache_line_size; > >> On other hand 128 value is very conservative and should satisfy all >> current platform VM run on. But you will wast java heap space. > > We can live with pessimistic value. That's the price we pay for dodging > false sharing on the platforms with hardware prefetchers turned on. OK. > >> There is no explanation in code what contending groups are. The only >> comment I see: >> >> + if (fs.contended_group() == 0) { >> + // special case, this default group is padded within >> >> Why other groups don't need padding between fields? > > That is by the definition of contended group. Contended group defines > the equivalence class over the fields: the fields within the same > contended group are not inter-padded. The only exception is default > group, which does not incur the equivalence, and so requires > intra-padding. I tempted not to go in the detail in HotSpot code, > because that is (to be) explained in the @Contended Javadoc: > http://gee.cs.oswego.edu/dl/jsr166/src/dl/sun/misc/sun/misc/Contended.html > (which is, but the weird legalese reason, can not be committed in > OpenJDK first, and then pushed to jsr166). You don't need to put details, just what you said is enough: "Contended group defines the equivalence class over the fields: the fields within the same contended group are not inter-padded. The only exception is default group, which does not incur the equivalence, and so requires intra-padding." > >> Also why you padding after fields again? You did padding before fields >> already? You can wasting space at the end of object or in between super >> and subclass fields. > > Yes, and that is expected: the padding in the end saves us from false > sharing against either subclass fields, or the header/fields of adjacent > object. The adjacent object can be unpadded (generally we don't even > know what that object is). Add comment to help a next developer who will touch this code. > >> In vmSymbols.hpp Contended signature should not be in "error klasses" >> group. Separate it by comment. > > Cosmetics; can be updated before the push. But you do that, sponsor will not do that. > >> In the test change copyright year to 2013. Also @summary should be bug's >> "Support Contended Annotation - JEP 142" > > Ditto. Cosmetics; can be updated before the push. Same. Vladimir > > -Aleksey. > From vitalyd at gmail.com Fri Jan 11 14:31:31 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Jan 2013 17:31:31 -0500 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F088EB.3030004@cs.oswego.edu> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50EFC7B0.1000205@oracle.com> <50F0866C.6030000@oracle.com> <50F088EB.3030004@cs.oswego.edu> Message-ID: Yes I understand the issue, and I need to check this, but I'd hope the OS and/or CPU would report the proper coherence unit. Most use cases for querying this info actually cares about the coherence unit size, so if they under report the size then those query capabilities are of almost no value (knowing that a line is 64 bytes isn't that interesting if CPU always fetches two of them). So my point was that I'd think it's possible to get this info without hard coding and erring on the high side. Thanks Sent from my phone On Jan 11, 2013 4:50 PM, "Doug Lea"
wrote: > > On 01/11/2013 05:14 PM, Vitaly Davidovich wrote: >> > > I still think it would be better to get line size from OS (or CPU) >>> rather than hardcoding a default - this seems orthogonal to the >>> prefetcher issue since the default you picked is probably going to be >>> either the same size or larger than what os/CPU would've reported. >>> >> > In case it helps resolve this a bit: > > The logistic problem is that we do not know a way to > reliably compute the effective cacheline length given > the possibility (and these days, likelihood) of adjacent > prefetching or other memory system quirks. And unreliable > detection is worse than no detection. So, in the near > term, the only course of action is to set this up using > reasonable defaults, and improve them over time. > Which is what Aleksey did. > > -Doug > > From vitalyd at gmail.com Fri Jan 11 14:34:43 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Jan 2013 17:34:43 -0500 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50EFC7B0.1000205@oracle.com> <50F0866C.6030000@oracle.com> <50F088EB.3030004@cs.oswego.edu> Message-ID: Sorry, typo - I meant to say it's not interesting if CPU treats two adjacent lines as a coherence unit, not for prefetch. Sent from my phone On Jan 11, 2013 5:31 PM, "Vitaly Davidovich" wrote: > Yes I understand the issue, and I need to check this, but I'd hope the OS > and/or CPU would report the proper coherence unit. Most use cases for > querying this info actually cares about the coherence unit size, so if they > under report the size then those query capabilities are of almost no value > (knowing that a line is 64 bytes isn't that interesting if CPU always > fetches two of them). So my point was that I'd think it's possible to get > this info without hard coding and erring on the high side. > > Thanks > > Sent from my phone > On Jan 11, 2013 4:50 PM, "Doug Lea"
wrote: > >> >> On 01/11/2013 05:14 PM, Vitaly Davidovich wrote: >>> >> >> I still think it would be better to get line size from OS (or CPU) >>>> rather than hardcoding a default - this seems orthogonal to the >>>> prefetcher issue since the default you picked is probably going to be >>>> either the same size or larger than what os/CPU would've reported. >>>> >>> >> In case it helps resolve this a bit: >> >> The logistic problem is that we do not know a way to >> reliably compute the effective cacheline length given >> the possibility (and these days, likelihood) of adjacent >> prefetching or other memory system quirks. And unreliable >> detection is worse than no detection. So, in the near >> term, the only course of action is to set this up using >> reasonable defaults, and improve them over time. >> Which is what Aleksey did. >> >> -Doug >> >> From aleksey.shipilev at oracle.com Fri Jan 11 15:11:17 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 03:11:17 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F08DCE.1060907@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> Message-ID: <50F09C15.5090501@oracle.com> On 01/12/2013 02:10 AM, Vladimir Kozlov wrote: > I mentioned this because for previous your changes "8004330: Add missing > Unsafe entry points" I had to do it for you. You should make life of > your sponsor better and not worse, we have a lot of other things to do. OK, sounds fair. I wish you had this explanation in 8004330 timeframe. I was under the false impression this is how we do the coordinated HotSpot-JDK change. > As Joe responded we can use the same bug id or create subCR. I rises > this question because of long conversation thread this week about jdk > changes for, again, 8004330 when library guys did not know what happened > with the changes. Ok, you want me to ask corelibs guys to push JDK side of changes on their own? You will have to wait with HotSpot update then, because that otherwise it would render jtreg test non-compilable. I left @Contended in HotSpot webrev, so that is still separately compilable: http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/ I will post JDK changes for reviews shortly. >> Beefing up ContendedPaddingWidth when larger cache line was detected is >> fine. But, will user setting be favored this way? I would like to be >> able to set it lower than the cache line size for perf testing. > > You can accomplish this with: > > if (FLAG_IS_DEFAULT(ContendedPaddingWidth) && > (cache_line_size > ContendedPaddingWidth)) > ContendedPaddingWidth = cache_line_size; Added. Debug printing is also added. > You don't need to put details, just what you said is enough: > > "Contended group defines the equivalence class over the fields: the > fields within the same contended group are not inter-padded. The only > exception is default group, which does not incur the equivalence, and so > requires intra-padding." Added this at the code points which confused you. >>> Also why you padding after fields again? You did padding before fields >>> already? You can wasting space at the end of object or in between super >>> and subclass fields. >> >> Yes, and that is expected: the padding in the end saves us from false >> sharing against either subclass fields, or the header/fields of adjacent >> object. The adjacent object can be unpadded (generally we don't even >> know what that object is). > > Add comment to help a next developer who will touch this code. Added. >> >>> In vmSymbols.hpp Contended signature should not be in "error klasses" >>> group. Separate it by comment. >> >> Cosmetics; can be updated before the push. > > But you do that, sponsor will not do that. Yeah, I didn't mean sponsor should do it. Rather, I was pointing this is a trivial change which could be fixed without a review. Fixed, I had also consumed AbstractOwnableSynchronized in the same group. >> >>> In the test change copyright year to 2013. Also @summary should be bug's >>> "Support Contended Annotation - JEP 142" >> >> Ditto. Cosmetics; can be updated before the push. > > Same. Fixed. -Aleksey. From christian.thalinger at oracle.com Fri Jan 11 15:17:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 15:17:24 -0800 Subject: HotSpot Changes in 7u In-Reply-To: <50F06332.9000805@LGonQn.Org> References: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> <50F06332.9000805@LGonQn.Org> Message-ID: <391E6E12-A1EF-4C4C-B002-DD92A4114447@oracle.com> On Jan 11, 2013, at 11:08 AM, Chris Phillips @ T O wrote: > Hi > > On 11/01/13 12:29 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 21/12/2012 9:51 AM, Coleen Phillimore wrote: >>>> I am checking these changes into hsx24 now. >>> Thanks Coleen. >>> >> Yes, thanks Coleen for taking this on. I see they've now appeared in 7u/hotspot. >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71 >> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9d98c1eb82b0 >> >> Any chance of getting: >> >> 8000780: make Zero build and run with JDK8 >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5 > This required a backport that has been reviewed by Roman and > Christian (Thanks!). Right. I remember reviewing this. But I'm not sure if it's not already too late to make 7u12. Alejandro would know. -- Chris > > See attached email's from Alejandro and Christian. > > >> >> in too? Or is it not appropriate? >> >> CCing the original reviewers & author. >> > Chris > > From alejandro.murillo at oracle.com Fri Jan 11 15:15:48 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 11 Jan 2013 23:15:48 +0000 Subject: hg: hsx/hsx24/hotspot: 8006035: new hotspot build - hs24-b30 Message-ID: <20130111231551.4D5024720D@hg.openjdk.java.net> Changeset: f5bd894b0db4 Author: amurillo Date: 2013-01-11 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f5bd894b0db4 8006035: new hotspot build - hs24-b30 Reviewed-by: jcoomes ! make/hotspot_version From aleksey.shipilev at oracle.com Fri Jan 11 15:23:24 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 03:23:24 +0400 Subject: RFR (XS): CR 8003985: Support @Contended annotation Message-ID: <50F09EEC.1030009@oracle.com> Hi guys, This is the JDK side of changes for supporting @Contended: http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ Status: - This change is ready to be pushed; due to licensing reasons with jsr166, we can only commit the stub; regular jsr166 sync will bring the updated annotation later. - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) - CCC is in place, and Approved. I need a sponsor to push this. Thanks, -Aleksey. From joe.darcy at oracle.com Fri Jan 11 15:36:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jan 2013 15:36:30 -0800 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F09EEC.1030009@oracle.com> References: <50F09EEC.1030009@oracle.com> Message-ID: <50F0A1FE.9090804@oracle.com> On 01/11/2013 03:23 PM, Aleksey Shipilev wrote: > Hi guys, > > This is the JDK side of changes for supporting @Contended: > http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ > > Status: > - This change is ready to be pushed; due to licensing reasons with > jsr166, we can only commit the stub; regular jsr166 sync will bring the > updated annotation later. > - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) > - CCC is in place, and Approved. > > I need a sponsor to push this. > > Thanks, > -Aleksey. Looks fine; approved. Thanks, -Joe From vladimir.kozlov at oracle.com Fri Jan 11 15:40:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 15:40:15 -0800 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F09C15.5090501@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> Message-ID: <50F0A2DF.8070003@oracle.com> On 1/11/13 3:11 PM, Aleksey Shipilev wrote: > On 01/12/2013 02:10 AM, Vladimir Kozlov wrote: >> I mentioned this because for previous your changes "8004330: Add missing >> Unsafe entry points" I had to do it for you. You should make life of >> your sponsor better and not worse, we have a lot of other things to do. > > OK, sounds fair. I wish you had this explanation in 8004330 timeframe. I > was under the false impression this is how we do the coordinated > HotSpot-JDK change. We (VM group) can push jdk changes again using hotspot-main/jdk repo as with 8004330 to synchronize push. I just want a separate webrev for lib changes to let lib guys know what is coming to them. Also VM push process (JPRT) does not do automatic push into jdk code together with VM changes - it is 2 different jobs. So we have to separate Hotspot and JDK changes. > >> As Joe responded we can use the same bug id or create subCR. I rises >> this question because of long conversation thread this week about jdk >> changes for, again, 8004330 when library guys did not know what happened >> with the changes. > > Ok, you want me to ask corelibs guys to push JDK side of changes on > their own? You will have to wait with HotSpot update then, because that > otherwise it would render jtreg test non-compilable. I left @Contended > in HotSpot webrev, so that is still separately compilable: > http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/ This looks better. Please, fix copyright year in Contended.java > > I will post JDK changes for reviews shortly. Thanks, Vladimir > >>> Beefing up ContendedPaddingWidth when larger cache line was detected is >>> fine. But, will user setting be favored this way? I would like to be >>> able to set it lower than the cache line size for perf testing. >> >> You can accomplish this with: >> >> if (FLAG_IS_DEFAULT(ContendedPaddingWidth) && >> (cache_line_size > ContendedPaddingWidth)) >> ContendedPaddingWidth = cache_line_size; > > Added. Debug printing is also added. > >> You don't need to put details, just what you said is enough: >> >> "Contended group defines the equivalence class over the fields: the >> fields within the same contended group are not inter-padded. The only >> exception is default group, which does not incur the equivalence, and so >> requires intra-padding." > > Added this at the code points which confused you. > >>>> Also why you padding after fields again? You did padding before fields >>>> already? You can wasting space at the end of object or in between super >>>> and subclass fields. >>> >>> Yes, and that is expected: the padding in the end saves us from false >>> sharing against either subclass fields, or the header/fields of adjacent >>> object. The adjacent object can be unpadded (generally we don't even >>> know what that object is). >> >> Add comment to help a next developer who will touch this code. > > Added. > >>> >>>> In vmSymbols.hpp Contended signature should not be in "error klasses" >>>> group. Separate it by comment. >>> >>> Cosmetics; can be updated before the push. >> >> But you do that, sponsor will not do that. > > Yeah, I didn't mean sponsor should do it. Rather, I was pointing this is > a trivial change which could be fixed without a review. > > Fixed, I had also consumed AbstractOwnableSynchronized in the same group. > >>> >>>> In the test change copyright year to 2013. Also @summary should be bug's >>>> "Support Contended Annotation - JEP 142" >>> >>> Ditto. Cosmetics; can be updated before the push. >> >> Same. > > Fixed. > > -Aleksey. > From aleksey.shipilev at oracle.com Fri Jan 11 15:47:23 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 03:47:23 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0A2DF.8070003@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> Message-ID: <50F0A48B.4040609@oracle.com> On 01/12/2013 03:40 AM, Vladimir Kozlov wrote: > On 1/11/13 3:11 PM, Aleksey Shipilev wrote: >> On 01/12/2013 02:10 AM, Vladimir Kozlov wrote: >>> I mentioned this because for previous your changes "8004330: Add missing >>> Unsafe entry points" I had to do it for you. You should make life of >>> your sponsor better and not worse, we have a lot of other things to do. >> >> OK, sounds fair. I wish you had this explanation in 8004330 timeframe. I >> was under the false impression this is how we do the coordinated >> HotSpot-JDK change. > > We (VM group) can push jdk changes again using hotspot-main/jdk repo as > with 8004330 to synchronize push. Ok, that was my impression as well. > I just want a separate webrev for lib changes to let lib guys know what > is coming to them. Ok. > Also VM push process (JPRT) does not do automatic push into jdk code > together with VM changes - it is 2 different jobs. So we have to > separate Hotspot and JDK changes. :( >> http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/ > This looks better. Please, fix copyright year in Contended.java Ah, I submitted the fixed year for JDK reviews. Fixed in VM webrev as well now. -Aleksey. From jesper.wilhelmsson at oracle.com Fri Jan 11 16:02:54 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sat, 12 Jan 2013 01:02:54 +0100 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0A48B.4040609@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> Message-ID: <50F0A82E.8090204@oracle.com> On 12/1/13 12:47 AM, Aleksey Shipilev wrote: > On 01/12/2013 03:40 AM, Vladimir Kozlov wrote: >> On 1/11/13 3:11 PM, Aleksey Shipilev wrote: >>> On 01/12/2013 02:10 AM, Vladimir Kozlov wrote: >>>> I mentioned this because for previous your changes "8004330: Add missing >>>> Unsafe entry points" I had to do it for you. You should make life of >>>> your sponsor better and not worse, we have a lot of other things to do. >>> OK, sounds fair. I wish you had this explanation in 8004330 timeframe. I >>> was under the false impression this is how we do the coordinated >>> HotSpot-JDK change. >> We (VM group) can push jdk changes again using hotspot-main/jdk repo as >> with 8004330 to synchronize push. > Ok, that was my impression as well. Aleksey, If I understand this correctly you don't need a separate sponsor for the jdk changes (you asked for a sponsor in the jdk webrev). Vladimir, are you suggesting that I push directly to hotspot-main? - all of it or just the jdk stuff? /Jesper > >> I just want a separate webrev for lib changes to let lib guys know what >> is coming to them. > Ok. > >> Also VM push process (JPRT) does not do automatic push into jdk code >> together with VM changes - it is 2 different jobs. So we have to >> separate Hotspot and JDK changes. > :( > >>> http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/ >> This looks better. Please, fix copyright year in Contended.java > Ah, I submitted the fixed year for JDK reviews. Fixed in VM webrev as > well now. > > -Aleksey. From vladimir.kozlov at oracle.com Fri Jan 11 16:22:46 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 16:22:46 -0800 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0A82E.8090204@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> Message-ID: <50F0ACD6.7000409@oracle.com> > Vladimir, are you suggesting that I push directly to hotspot-main? - all > of it or just the jdk stuff? > /Jesper Only jdk changes, Hotspot changes should go into group's repo. Don't forget to add Contributed-by into changeset's comment. I will do JDK push. I will create Sub-Task rfe, as Joe suggested, for jdk changes so we can track them separately. Thanks, Vladimir On 1/11/13 4:02 PM, Jesper Wilhelmsson wrote: > On 12/1/13 12:47 AM, Aleksey Shipilev wrote: >> On 01/12/2013 03:40 AM, Vladimir Kozlov wrote: >>> On 1/11/13 3:11 PM, Aleksey Shipilev wrote: >>>> On 01/12/2013 02:10 AM, Vladimir Kozlov wrote: >>>>> I mentioned this because for previous your changes "8004330: Add >>>>> missing >>>>> Unsafe entry points" I had to do it for you. You should make life of >>>>> your sponsor better and not worse, we have a lot of other things to >>>>> do. >>>> OK, sounds fair. I wish you had this explanation in 8004330 >>>> timeframe. I >>>> was under the false impression this is how we do the coordinated >>>> HotSpot-JDK change. >>> We (VM group) can push jdk changes again using hotspot-main/jdk repo as >>> with 8004330 to synchronize push. >> Ok, that was my impression as well. > > Aleksey, If I understand this correctly you don't need a separate > sponsor for the jdk changes (you asked for a sponsor in the jdk webrev). > > Vladimir, are you suggesting that I push directly to hotspot-main? - all > of it or just the jdk stuff? > /Jesper > >> >>> I just want a separate webrev for lib changes to let lib guys know what >>> is coming to them. >> Ok. >> >>> Also VM push process (JPRT) does not do automatic push into jdk code >>> together with VM changes - it is 2 different jobs. So we have to >>> separate Hotspot and JDK changes. >> :( >> >>>> http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/ >>> This looks better. Please, fix copyright year in Contended.java >> Ah, I submitted the fixed year for JDK reviews. Fixed in VM webrev as >> well now. >> >> -Aleksey. > From aleksey.shipilev at oracle.com Fri Jan 11 16:25:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 04:25:43 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0ACD6.7000409@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <50F0ACD6.7000409@oracle.com> Message-ID: <50F0AD87.3080804@oracle.com> On 01/12/2013 04:22 AM, Vladimir Kozlov wrote: > I will do JDK push. I will create Sub-Task rfe, as Joe suggested, for > jdk changes so we can track them separately. To get this straight this time. Was I supposed to do this when submitting the corelibs review? I thought "reusing the CR number" meant we can go without sub-task. -Aleksey. From vladimir.kozlov at oracle.com Fri Jan 11 16:37:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 16:37:23 -0800 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0AD87.3080804@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <50F0ACD6.7000409@oracle.com> <50F0AD87.3080804@oracle.com> Message-ID: <50F0B043.6050803@oracle.com> On 1/11/13 4:25 PM, Aleksey Shipilev wrote: > On 01/12/2013 04:22 AM, Vladimir Kozlov wrote: >> I will do JDK push. I will create Sub-Task rfe, as Joe suggested, for >> jdk changes so we can track them separately. > > To get this straight this time. Was I supposed to do this when > submitting the corelibs review? I thought "reusing the CR number" meant > we can go without sub-task. Yes, it is preferable to have different CR ID since we are pushing changes separately and into different places but it should be Sub-Task to get them connected. I already created one 8006123. Vladimir > > -Aleksey. > From vladimir.kozlov at oracle.com Fri Jan 11 16:51:43 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 12 Jan 2013 00:51:43 +0000 Subject: hg: hsx/hotspot-main/jdk: 8006123: Support @Contended Annotation - JEP 142 (jdk part) Message-ID: <20130112005156.A8EC947210@hg.openjdk.java.net> Changeset: 9d5c43050210 Author: dl Date: 2013-01-11 16:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 8006123: Support @Contended Annotation - JEP 142 (jdk part) Summary: jdk changes for 8003895. Reviewed-by: darcy, jrose, coleenp, dholmes, kvn Contributed-by: Aleksey Shipilev + src/share/classes/sun/misc/Contended.java From erik.helin at oracle.com Sat Jan 12 00:27:56 2013 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 12 Jan 2013 09:27:56 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize Message-ID: <50F11E8C.5070302@oracle.com> Hi all, this change sets MaxNewSize to always be less than or equal to MaxHeapSize. The current default value is max_uintx. Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ RFE: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 Analysis: The change should not affect the existing code. The case that has to be analyzed is when MaxNewSize is not set on the command line, since the update of MaxNewSize is guarded by "if (FLAG_IS_DEFAULT(MaxNewSize))". MaxNewSize is only used in the following files: - g1CollectorPolicy.cpp: Guards all the usage of MaxNewSize in if statements: if (FLAG_IS_CMDLINE(MaxNewSize)) { ... } Since this change uses FLAG_SET_DEFAULT, this change won't affect this code path. - arguments.cpp: Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. Otherwise, only writes new values to MaxNewSize that are not based on the value of MaxNewSize. This code is not affected since the value of FLAG_IS_DEFAULT(MaxNewSize) is not affected. - collectorPolicy.cpp: MaxNewSize is used in a couple of places: if (NewSize > MaxNewSize) { MaxNewSize = NewSize; } If both NewSize and MaxNewSize have their default values, then NewSize is ScaleForWordSize(1*M) which will always be less than MaxNewSize which now is MaxHeapSize. The semantics of the if statement is only changed if NewSize is set on the command line to a value larger than MaxHeapSize, which is not a valid case. if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { ... } else { max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); } This "if" check will still follow the "else" branch in the default case, just as before, since FLAG_SET_DEFAULT is used in this change. The semantics of the calculation in the else branch is also preserved, since MAX2(max_new_size, NewSize) will still always be less than MaxNewSize for all valid values of NewSize. Testing: Before the change: java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' uintx MaxHeapSize := 2017460224 {product} uintx MaxNewSize = 18446744073709486080 {product} After the change: java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' uintx MaxHeapSize := 2017460224 {product} uintx MaxNewSize = 2015428608 {product} JPRT Thanks, Erik From alejandro.murillo at oracle.com Sat Jan 12 04:53:36 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Sat, 12 Jan 2013 05:53:36 -0700 Subject: HotSpot Changes in 7u In-Reply-To: <391E6E12-A1EF-4C4C-B002-DD92A4114447@oracle.com> References: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> <50F06332.9000805@LGonQn.Org> <391E6E12-A1EF-4C4C-B002-DD92A4114447@oracle.com> Message-ID: <50F15CD0.8090301@oracle.com> On 1/11/2013 4:17 PM, Christian Thalinger wrote: > On Jan 11, 2013, at 11:08 AM, Chris Phillips @ T O wrote: > >> Hi >> >> On 11/01/13 12:29 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> On 21/12/2012 9:51 AM, Coleen Phillimore wrote: >>>>> I am checking these changes into hsx24 now. >>>> Thanks Coleen. >>>> >>> Yes, thanks Coleen for taking this on. I see they've now appeared in 7u/hotspot. >>> >>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71 >>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9d98c1eb82b0 >>> >>> Any chance of getting: >>> >>> 8000780: make Zero build and run with JDK8 >>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5 >> This required a backport that has been reviewed by Roman and >> Christian (Thanks!). > Right. I remember reviewing this. But I'm not sure if it's not already too late to make 7u12. Alejandro would know.\ No it's not too late. We didn't take snapshots in the last couple of weeks (unable to run PIT), I did a last minute snap this week and will probably do one next week but we want to reserve these for testing new features only, based on the 7u12 schedule, after that we have a few more weeks for bug fixing and I will make sure to get this in. Hopefully this patch will still apply. Apologies for the delay Thanks Alejandro > > -- Chris > >> See attached email's from Alejandro and Christian. >> >> >>> in too? Or is it not appropriate? >>> >>> CCing the original reviewers & author. >>> >> Chris >> >> From vladimir.kozlov at oracle.com Sat Jan 12 09:12:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 12 Jan 2013 09:12:34 -0800 Subject: HotSpot Changes in 7u (8000780: make Zero build run with JDK8) In-Reply-To: <50F15CD0.8090301@oracle.com> References: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> <50F06332.9000805@LGonQn.Org> <391E6E12-A1EF-4C4C-B002-DD92A4114447@oracle.com> <50F15CD0.8090301@oracle.com> Message-ID: <50F19982.3010200@oracle.com> Andrew, The patch needs to be redone for 7u. Current will not apply because it is affected by PermGen removal changes. Would be nice to change bug's Synopsis also since it will be not for jdk8. Vladimir On 1/12/13 4:53 AM, Alejandro E Murillo wrote: > > On 1/11/2013 4:17 PM, Christian Thalinger wrote: >> On Jan 11, 2013, at 11:08 AM, Chris Phillips @ T O >> wrote: >> >>> Hi >>> >>> On 11/01/13 12:29 PM, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> On 21/12/2012 9:51 AM, Coleen Phillimore wrote: >>>>>> I am checking these changes into hsx24 now. >>>>> Thanks Coleen. >>>>> >>>> Yes, thanks Coleen for taking this on. I see they've now appeared >>>> in 7u/hotspot. >>>> >>>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71 >>>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9d98c1eb82b0 >>>> >>>> Any chance of getting: >>>> >>>> 8000780: make Zero build and run with JDK8 >>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5 >>> This required a backport that has been reviewed by Roman and >>> Christian (Thanks!). >> Right. I remember reviewing this. But I'm not sure if it's not >> already too late to make 7u12. Alejandro would know.\ > No it's not too late. > We didn't take snapshots in the last couple of weeks (unable to run PIT), > I did a last minute snap this week and will probably do one next week > but we want to reserve these for testing new features only, based on > the 7u12 schedule, > after that we have a few more weeks for bug fixing and I will make sure to > get this in. Hopefully this patch will still apply. Apologies for the delay > > Thanks > Alejandro > >> >> -- Chris >> >>> See attached email's from Alejandro and Christian. >>> >>> >>>> in too? Or is it not appropriate? >>>> >>>> CCing the original reviewers & author. >>>> >>> Chris >>> >>> From Alan.Bateman at oracle.com Sun Jan 13 07:05:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Jan 2013 15:05:58 +0000 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F09EEC.1030009@oracle.com> References: <50F09EEC.1030009@oracle.com> Message-ID: <50F2CD56.4050904@oracle.com> On 11/01/2013 23:23, Aleksey Shipilev wrote: > Hi guys, > > This is the JDK side of changes for supporting @Contended: > http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ > > Status: > - This change is ready to be pushed; due to licensing reasons with > jsr166, we can only commit the stub; regular jsr166 sync will bring the > updated annotation later. > - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) > - CCC is in place, and Approved. > > I need a sponsor to push this. > Looks fine (although I do not like seeing this going into sun.misc). Do you want this to go into in via jdk8/tl? If so I can push it for you today, just let me know. -Alan. From vladimir.kozlov at oracle.com Sun Jan 13 10:30:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 13 Jan 2013 10:30:57 -0800 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F2CD56.4050904@oracle.com> References: <50F09EEC.1030009@oracle.com> <50F2CD56.4050904@oracle.com> Message-ID: <50F2FD61.2090107@oracle.com> Thank you, Alan I already pushed it into hotspot/jdk: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 We will promote it as we did before with similar changes together with Hotspot changes. Thanks, Vladimir On 1/13/13 7:05 AM, Alan Bateman wrote: > On 11/01/2013 23:23, Aleksey Shipilev wrote: >> Hi guys, >> >> This is the JDK side of changes for supporting @Contended: >> http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ >> >> Status: >> - This change is ready to be pushed; due to licensing reasons with >> jsr166, we can only commit the stub; regular jsr166 sync will bring the >> updated annotation later. >> - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) >> - CCC is in place, and Approved. >> >> I need a sponsor to push this. >> > Looks fine (although I do not like seeing this going into sun.misc). > > Do you want this to go into in via jdk8/tl? If so I can push it for you > today, just let me know. > > -Alan. From david.holmes at oracle.com Sun Jan 13 15:23:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 09:23:10 +1000 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F2FD61.2090107@oracle.com> References: <50F09EEC.1030009@oracle.com> <50F2CD56.4050904@oracle.com> <50F2FD61.2090107@oracle.com> Message-ID: <50F341DE.6000908@oracle.com> On 14/01/2013 4:30 AM, Vladimir Kozlov wrote: > Thank you, Alan > > I already pushed it into hotspot/jdk: > > http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 > > We will promote it as we did before with similar changes together with > Hotspot changes. So this seem to be becoming a new process for avoiding flag days - which is not a bad thing. But previously this was only a special exception for jsr-292 and now we seem to be generalizing it without there being any proper discussion to ensure all the right pieces are place to do this and so that everyone knows what is being done. David ----- > Thanks, > Vladimir > > On 1/13/13 7:05 AM, Alan Bateman wrote: >> On 11/01/2013 23:23, Aleksey Shipilev wrote: >>> Hi guys, >>> >>> This is the JDK side of changes for supporting @Contended: >>> http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ >>> >>> Status: >>> - This change is ready to be pushed; due to licensing reasons with >>> jsr166, we can only commit the stub; regular jsr166 sync will bring the >>> updated annotation later. >>> - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) >>> - CCC is in place, and Approved. >>> >>> I need a sponsor to push this. >>> >> Looks fine (although I do not like seeing this going into sun.misc). >> >> Do you want this to go into in via jdk8/tl? If so I can push it for you >> today, just let me know. >> >> -Alan. From david.holmes at oracle.com Sun Jan 13 16:25:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 10:25:14 +1000 Subject: Code review request: 8005936,PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50F02D29.30608@oracle.com> References: <50EF2B24.9030500@oracle.com> <50EF9D67.8000806@oracle.com> <50F02D29.30608@oracle.com> Message-ID: <50F3506A.1090507@oracle.com> On 12/01/2013 1:18 AM, Zhengyu Gu wrote: > Thanks, David. > > My bad, I do mean JVM exit handler, but rushed ... > Here is updated webrev: > > http://cr.openjdk.java.net/~zgu/8005936/webrev.01/ Why put it at the end of before_exit instead of just putting it after the call to before_exit ? David > Thanks, > > -Zhengyu > > On 1/11/2013 12:04 AM, David Holmes wrote: >> On 11/01/2013 6:57 AM, Zhengyu Gu wrote: >>> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT >>> memory statistics can be reported when PrintNMTStatistics flag is >>> enabled. >>> >>> webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ >> >> print_statistics() seems the wrong place to put the shutdown code. >> Plus you only added it to the non-product path. >> >> David >> >>> Tests: >>> >>> 1. JPRT tests >>> 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 >>> and x64 >>> >>> >>> Thanks, >>> >>> -Zhengyu From zhengyu.gu at oracle.com Sun Jan 13 18:07:29 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Sun, 13 Jan 2013 21:07:29 -0500 Subject: Code review request: 8005936, PrintNMTStatistics doesn't work for normal JVM exit In-Reply-To: <50F3506A.1090507@oracle.com> References: <50EF2B24.9030500@oracle.com> <50EF9D67.8000806@oracle.com> <50F02D29.30608@oracle.com> <50F3506A.1090507@oracle.com> Message-ID: <9A6A1D7D-30BF-44CF-BA31-4ACCBB4ACBEF@oracle.com> As mentioned in comment, NMT has to be shutdown before VM exit, so I think it is the place as function name suggested. -Zhengyu Sent from my iPhone On Jan 13, 2013, at 7:25 PM, David Holmes wrote: > On 12/01/2013 1:18 AM, Zhengyu Gu wrote: >> Thanks, David. >> >> My bad, I do mean JVM exit handler, but rushed ... >> Here is updated webrev: >> >> http://cr.openjdk.java.net/~zgu/8005936/webrev.01/ > > Why put it at the end of before_exit instead of just putting it after the call to before_exit ? > > David > >> Thanks, >> >> -Zhengyu >> >> On 1/11/2013 12:04 AM, David Holmes wrote: >>> On 11/01/2013 6:57 AM, Zhengyu Gu wrote: >>>> Moved NMT shutdown code to JVM exit handler, so guarantees that NMT >>>> memory statistics can be reported when PrintNMTStatistics flag is >>>> enabled. >>>> >>>> webrev: http://cr.openjdk.java.net/~zgu/8005936/webrev.00/ >>> >>> print_statistics() seems the wrong place to put the shutdown code. >>> Plus you only added it to the non-product path. >>> >>> David >>> >>>> Tests: >>>> >>>> 1. JPRT tests >>>> 2. UTE vm.quick.testlist on Windows x64, Solaris sparv9, Linux x32 >>>> and x64 >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu From christian.thalinger at oracle.com Mon Jan 14 10:49:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Jan 2013 10:49:51 -0800 Subject: HotSpot Changes in 7u (8000780: make Zero build run with JDK8) In-Reply-To: <50F19982.3010200@oracle.com> References: <905417250.3621621.1357925361745.JavaMail.root@redhat.com> <50F06332.9000805@LGonQn.Org> <391E6E12-A1EF-4C4C-B002-DD92A4114447@oracle.com> <50F15CD0.8090301@oracle.com> <50F19982.3010200@oracle.com> Message-ID: On Jan 12, 2013, at 9:12 AM, Vladimir Kozlov wrote: > Andrew, > > The patch needs to be redone for 7u. Current will not apply because it is affected by PermGen removal changes. Would be nice to change bug's Synopsis also since it will be not for jdk8. I double checked this and the patch I reviewed was for 7u. -- Chris > > Vladimir > > On 1/12/13 4:53 AM, Alejandro E Murillo wrote: >> >> On 1/11/2013 4:17 PM, Christian Thalinger wrote: >>> On Jan 11, 2013, at 11:08 AM, Chris Phillips @ T O >>> wrote: >>> >>>> Hi >>>> >>>> On 11/01/13 12:29 PM, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> On 21/12/2012 9:51 AM, Coleen Phillimore wrote: >>>>>>> I am checking these changes into hsx24 now. >>>>>> Thanks Coleen. >>>>> Yes, thanks Coleen for taking this on. I see they've now appeared >>>>> in 7u/hotspot. >>>>> >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71 >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/9d98c1eb82b0 >>>>> >>>>> Any chance of getting: >>>>> >>>>> 8000780: make Zero build and run with JDK8 >>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5 >>>> This required a backport that has been reviewed by Roman and >>>> Christian (Thanks!). >>> Right. I remember reviewing this. But I'm not sure if it's not >>> already too late to make 7u12. Alejandro would know.\ >> No it's not too late. >> We didn't take snapshots in the last couple of weeks (unable to run PIT), >> I did a last minute snap this week and will probably do one next week >> but we want to reserve these for testing new features only, based on >> the 7u12 schedule, >> after that we have a few more weeks for bug fixing and I will make sure to >> get this in. Hopefully this patch will still apply. Apologies for the delay >> >> Thanks >> Alejandro >> >>> >>> -- Chris >>> >>>> See attached email's from Alejandro and Christian. >>>> >>>> >>>>> in too? Or is it not appropriate? >>>>> >>>>> CCing the original reviewers & author. >>>> Chris >>>> >>>> From jon.masamitsu at oracle.com Mon Jan 14 12:41:28 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 14 Jan 2013 12:41:28 -0800 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F11E8C.5070302@oracle.com> References: <50F11E8C.5070302@oracle.com> Message-ID: <50F46D78.5050306@oracle.com> Erik, Change looks good. Do you think it would fit better in TwoGenCollectorPolicy::initialize_flags() or maybe GenCollectorPolicy::initialize_flags()? You'd have to add it also to G1CollectorPolicy::initialize_flags() or do some refactoring of the various initialize_flags(). Jon On 01/12/13 00:27, Erik Helin wrote: > Hi all, > > this change sets MaxNewSize to always be less than or equal to > MaxHeapSize. The current default value is max_uintx. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ > > RFE: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 > > Analysis: > The change should not affect the existing code. The case that has to > be analyzed is when MaxNewSize is not set on the command line, since > the update of MaxNewSize is guarded by "if > (FLAG_IS_DEFAULT(MaxNewSize))". > > MaxNewSize is only used in the following files: > > - g1CollectorPolicy.cpp: > Guards all the usage of MaxNewSize in if statements: > > if (FLAG_IS_CMDLINE(MaxNewSize)) { > ... > } > > Since this change uses FLAG_SET_DEFAULT, this change won't affect > this code path. > > - arguments.cpp: > Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. > Otherwise, only writes new values to MaxNewSize that are not based on > the value of MaxNewSize. This code is not affected since the value of > FLAG_IS_DEFAULT(MaxNewSize) is not affected. > > - collectorPolicy.cpp: > MaxNewSize is used in a couple of places: > > if (NewSize > MaxNewSize) { > MaxNewSize = NewSize; > } > > If both NewSize and MaxNewSize have their default values, then > NewSize is ScaleForWordSize(1*M) which will always be less than > MaxNewSize which now is MaxHeapSize. The semantics of the if > statement is only changed if NewSize is set on the command line to a > value larger than MaxHeapSize, which is not a valid case. > > if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { > ... > } else { > max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); > max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); > } > > This "if" check will still follow the "else" branch in the default > case, just as before, since FLAG_SET_DEFAULT is used in this change. > The semantics of the calculation in the else branch is also preserved, > since MAX2(max_new_size, NewSize) will still always be less than > MaxNewSize for all valid values of NewSize. > > Testing: > Before the change: > java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' > uintx MaxHeapSize := 2017460224 {product} > uintx MaxNewSize = 18446744073709486080 {product} > > After the change: > java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' > uintx MaxHeapSize := 2017460224 {product} > uintx MaxNewSize = 2015428608 {product} > > JPRT > > Thanks, > Erik From jesper.wilhelmsson at oracle.com Mon Jan 14 14:20:45 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 14 Jan 2013 23:20:45 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F11E8C.5070302@oracle.com> References: <50F11E8C.5070302@oracle.com> Message-ID: <50F484BD.5060309@oracle.com> Looks good. And since it's the season: the copyright should be 2013 ;-) Ship it! /Jesper On 12/1/13 9:27 AM, Erik Helin wrote: > Hi all, > > this change sets MaxNewSize to always be less than or equal to > MaxHeapSize. The current default value is max_uintx. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ > > RFE: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 > > Analysis: > The change should not affect the existing code. The case that has to > be analyzed is when MaxNewSize is not set on the command line, since > the update of MaxNewSize is guarded by "if > (FLAG_IS_DEFAULT(MaxNewSize))". > > MaxNewSize is only used in the following files: > > - g1CollectorPolicy.cpp: > Guards all the usage of MaxNewSize in if statements: > > if (FLAG_IS_CMDLINE(MaxNewSize)) { > ... > } > > Since this change uses FLAG_SET_DEFAULT, this change won't affect > this code path. > > - arguments.cpp: > Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. > Otherwise, only writes new values to MaxNewSize that are not based on > the value of MaxNewSize. This code is not affected since the value of > FLAG_IS_DEFAULT(MaxNewSize) is not affected. > > - collectorPolicy.cpp: > MaxNewSize is used in a couple of places: > > if (NewSize > MaxNewSize) { > MaxNewSize = NewSize; > } > > If both NewSize and MaxNewSize have their default values, then > NewSize is ScaleForWordSize(1*M) which will always be less than > MaxNewSize which now is MaxHeapSize. The semantics of the if > statement is only changed if NewSize is set on the command line to a > value larger than MaxHeapSize, which is not a valid case. > > if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { > ... > } else { > max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); > max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); > } > > This "if" check will still follow the "else" branch in the default > case, just as before, since FLAG_SET_DEFAULT is used in this change. > The semantics of the calculation in the else branch is also preserved, > since MAX2(max_new_size, NewSize) will still always be less than > MaxNewSize for all valid values of NewSize. > > Testing: > Before the change: > java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' > uintx MaxHeapSize := 2017460224 {product} > uintx MaxNewSize = 18446744073709486080 {product} > > After the change: > java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' > uintx MaxHeapSize := 2017460224 {product} > uintx MaxNewSize = 2015428608 {product} > > JPRT > > Thanks, > Erik From erik.helin at oracle.com Tue Jan 15 06:45:18 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 15 Jan 2013 15:45:18 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F46D78.5050306@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> Message-ID: <50F56B7E.3070406@oracle.com> Jon, On 01/14/2013 09:41 PM, Jon Masamitsu wrote: > Change looks good. Thanks! On 01/14/2013 09:41 PM, Jon Masamitsu wrote: > Do you think it would > fit better in TwoGenCollectorPolicy::initialize_flags() > or maybe GenCollectorPolicy::initialize_flags()? You'd have to > add it also to G1CollectorPolicy::initialize_flags() > or do some refactoring of the various initialize_flags(). I don't want to duplicate the code by adding it to both G1CollectorPolicy and GenCollectorPolicy, but I agree that Arguments::set_heap_size might not be the best place for it. I've tried a few different approaches, and also discussed with Bengt and Jesper, and I think that one of the following approaches is the way to go: 1. Add a new function, Arguments::set_heap_generation_sizes(), that sets MaxNewSize. Jesper could add his code for OldSize in this function as well. Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ 2. Add the code to CollectorPolicy::initialize_flags(). Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ Both options have drawbacks: It does not feel right to add a function to arguments.cpp that handles GC specific flags. On the other hand, this has already been done quite extensively, but that is not an excuse for continue doing it. Adding the code to CollectorPolicy breaks the abstraction that CollectorPolicy is not supposed to know about generational heap collectors (although this has already happened, see CollectorPolicy::initialize_size_info). Out of these two, I would prefer the first option (adding a new function in arguments.cpp) and I think both options are better than duplicating the code. Which option do you prefer? Or would you prefer another solution? Thanks, Erik > Jon > > > On 01/12/13 00:27, Erik Helin wrote: >> Hi all, >> >> this change sets MaxNewSize to always be less than or equal to >> MaxHeapSize. The current default value is max_uintx. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >> >> RFE: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >> >> Analysis: >> The change should not affect the existing code. The case that has to >> be analyzed is when MaxNewSize is not set on the command line, since >> the update of MaxNewSize is guarded by "if >> (FLAG_IS_DEFAULT(MaxNewSize))". >> >> MaxNewSize is only used in the following files: >> >> - g1CollectorPolicy.cpp: >> Guards all the usage of MaxNewSize in if statements: >> >> if (FLAG_IS_CMDLINE(MaxNewSize)) { >> ... >> } >> >> Since this change uses FLAG_SET_DEFAULT, this change won't affect >> this code path. >> >> - arguments.cpp: >> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >> Otherwise, only writes new values to MaxNewSize that are not based on >> the value of MaxNewSize. This code is not affected since the value of >> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >> >> - collectorPolicy.cpp: >> MaxNewSize is used in a couple of places: >> >> if (NewSize > MaxNewSize) { >> MaxNewSize = NewSize; >> } >> >> If both NewSize and MaxNewSize have their default values, then >> NewSize is ScaleForWordSize(1*M) which will always be less than >> MaxNewSize which now is MaxHeapSize. The semantics of the if >> statement is only changed if NewSize is set on the command line to a >> value larger than MaxHeapSize, which is not a valid case. >> >> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >> ... >> } else { >> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >> } >> >> This "if" check will still follow the "else" branch in the default >> case, just as before, since FLAG_SET_DEFAULT is used in this change. >> The semantics of the calculation in the else branch is also preserved, >> since MAX2(max_new_size, NewSize) will still always be less than >> MaxNewSize for all valid values of NewSize. >> >> Testing: >> Before the change: >> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >> uintx MaxHeapSize := 2017460224 {product} >> uintx MaxNewSize = 18446744073709486080 {product} >> >> After the change: >> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >> uintx MaxHeapSize := 2017460224 {product} >> uintx MaxNewSize = 2015428608 {product} >> >> JPRT >> >> Thanks, >> Erik From jesper.wilhelmsson at oracle.com Tue Jan 15 10:25:58 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 15 Jan 2013 19:25:58 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F56B7E.3070406@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> Message-ID: <50F59F36.2060306@oracle.com> Erik, I would prefer solution number two for the same reason that I moved my old gen size fix out of arguments.cpp, the code in Arguments don't know about generations and if we can avoid adding that knowledge I think we should avoid it. CollectorPolicy already know about generations and I think it is the right place for this code. /Jesper On 15/1/13 3:45 PM, Erik Helin wrote: > Jon, > > On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >> Change looks good. > > Thanks! > > On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >> Do you think it would >> fit better in TwoGenCollectorPolicy::initialize_flags() >> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >> add it also to G1CollectorPolicy::initialize_flags() >> or do some refactoring of the various initialize_flags(). > > I don't want to duplicate the code by adding it to both > G1CollectorPolicy and GenCollectorPolicy, but I agree that > Arguments::set_heap_size might not be the best place for it. > > I've tried a few different approaches, and also discussed with Bengt > and Jesper, and I think that one of the following approaches is the > way to go: > > 1. Add a new function, Arguments::set_heap_generation_sizes(), that > sets MaxNewSize. Jesper could add his code for OldSize in this > function as well. > > Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ > > 2. Add the code to CollectorPolicy::initialize_flags(). > > Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ > > Both options have drawbacks: > > It does not feel right to add a function to arguments.cpp that handles > GC specific flags. On the other hand, this has already been done quite > extensively, but that is not an excuse for continue doing it. > > Adding the code to CollectorPolicy breaks the abstraction that > CollectorPolicy is not supposed to know about generational heap > collectors (although this has already happened, see > CollectorPolicy::initialize_size_info). > > Out of these two, I would prefer the first option (adding a new > function in arguments.cpp) and I think both options are better than > duplicating the code. > > Which option do you prefer? Or would you prefer another solution? > > Thanks, > Erik > >> Jon >> >> >> On 01/12/13 00:27, Erik Helin wrote: >>> Hi all, >>> >>> this change sets MaxNewSize to always be less than or equal to >>> MaxHeapSize. The current default value is max_uintx. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>> >>> RFE: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>> >>> Analysis: >>> The change should not affect the existing code. The case that has to >>> be analyzed is when MaxNewSize is not set on the command line, since >>> the update of MaxNewSize is guarded by "if >>> (FLAG_IS_DEFAULT(MaxNewSize))". >>> >>> MaxNewSize is only used in the following files: >>> >>> - g1CollectorPolicy.cpp: >>> Guards all the usage of MaxNewSize in if statements: >>> >>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>> ... >>> } >>> >>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>> this code path. >>> >>> - arguments.cpp: >>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>> Otherwise, only writes new values to MaxNewSize that are not based on >>> the value of MaxNewSize. This code is not affected since the value of >>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>> >>> - collectorPolicy.cpp: >>> MaxNewSize is used in a couple of places: >>> >>> if (NewSize > MaxNewSize) { >>> MaxNewSize = NewSize; >>> } >>> >>> If both NewSize and MaxNewSize have their default values, then >>> NewSize is ScaleForWordSize(1*M) which will always be less than >>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>> statement is only changed if NewSize is set on the command line to a >>> value larger than MaxHeapSize, which is not a valid case. >>> >>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>> ... >>> } else { >>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>> } >>> >>> This "if" check will still follow the "else" branch in the default >>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>> The semantics of the calculation in the else branch is also >>> preserved, >>> since MAX2(max_new_size, NewSize) will still always be less than >>> MaxNewSize for all valid values of NewSize. >>> >>> Testing: >>> Before the change: >>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>> uintx MaxHeapSize := 2017460224 {product} >>> uintx MaxNewSize = 18446744073709486080 {product} >>> >>> After the change: >>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>> uintx MaxHeapSize := 2017460224 {product} >>> uintx MaxNewSize = 2015428608 {product} >>> >>> JPRT >>> >>> Thanks, >>> Erik > From staffan.larsen at oracle.com Tue Jan 15 10:43:58 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Jan 2013 19:43:58 +0100 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F0A82E.8090204@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> Message-ID: <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> This change seems to have broken deadlock detection in SA. Here is the exception that I get: java.lang.RuntimeException: should not reach here at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) I haven't yet dug into the details. To reproduce, start any Java program, then run: > sudo build/linux/linux_amd64_compiler2/jvmg/hotspot -cp build/linux/linux_amd64_compiler2/generated/sa-jdi.jar sun.jvm.hotspot.tools.JStack Using java runtime at: /home/staffan/java/8latest/jre Attaching to process ID 28487, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.0-b15-internal-jvmg Deadlock Detection: java.lang.RuntimeException: should not reach here at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) at sun.jvm.hotspot.oops.Field.(Field.java:47) at sun.jvm.hotspot.oops.OopField.(OopField.java:42) at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:915) at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628) at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665) at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689) at sun.jvm.hotspot.oops.OopUtilities.initThreadFields(OopUtilities.java:220) at sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:292) at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:385) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) Can't print deadlocks:should not reach here On 12 jan 2013, at 01:02, Jesper Wilhelmsson wrote: > On 12/1/13 12:47 AM, Aleksey Shipilev wrote: >> On 01/12/2013 03:40 AM, Vladimir Kozlov wrote: >>> On 1/11/13 3:11 PM, Aleksey Shipilev wrote: >>>> On 01/12/2013 02:10 AM, Vladimir Kozlov wrote: >>>>> I mentioned this because for previous your changes "8004330: Add missing >>>>> Unsafe entry points" I had to do it for you. You should make life of >>>>> your sponsor better and not worse, we have a lot of other things to do. >>>> OK, sounds fair. I wish you had this explanation in 8004330 timeframe. I >>>> was under the false impression this is how we do the coordinated >>>> HotSpot-JDK change. >>> We (VM group) can push jdk changes again using hotspot-main/jdk repo as >>> with 8004330 to synchronize push. >> Ok, that was my impression as well. > > Aleksey, If I understand this correctly you don't need a separate sponsor for the jdk changes (you asked for a sponsor in the jdk webrev). > > Vladimir, are you suggesting that I push directly to hotspot-main? - all of it or just the jdk stuff? > /Jesper > >> >>> I just want a separate webrev for lib changes to let lib guys know what >>> is coming to them. >> Ok. >> >>> Also VM push process (JPRT) does not do automatic push into jdk code >>> together with VM changes - it is 2 different jobs. So we have to >>> separate Hotspot and JDK changes. >> :( >> >>>> http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/ >>> This looks better. Please, fix copyright year in Contended.java >> Ah, I submitted the fixed year for JDK reviews. Fixed in VM webrev as >> well now. >> >> -Aleksey. > From aleksey.shipilev at oracle.com Tue Jan 15 10:52:27 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 22:52:27 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> Message-ID: <50F5A56B.6060006@oracle.com> Sorry to hear it. Looking. Is this a part of regular test suite (which I had missed to run)? -Aleksey. On 01/15/2013 10:43 PM, Staffan Larsen wrote: > This change seems to have broken deadlock detection in SA. Here is the exception that I get: > > java.lang.RuntimeException: should not reach here > at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) > > I haven't yet dug into the details. To reproduce, start any Java program, then run: > >> sudo build/linux/linux_amd64_compiler2/jvmg/hotspot -cp build/linux/linux_amd64_compiler2/generated/sa-jdi.jar sun.jvm.hotspot.tools.JStack > > Using java runtime at: /home/staffan/java/8latest/jre > Attaching to process ID 28487, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 25.0-b15-internal-jvmg > Deadlock Detection: > > java.lang.RuntimeException: should not reach here > at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) > at sun.jvm.hotspot.oops.Field.(Field.java:47) > at sun.jvm.hotspot.oops.OopField.(OopField.java:42) > at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:915) > at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628) > at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665) > at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689) > at sun.jvm.hotspot.oops.OopUtilities.initThreadFields(OopUtilities.java:220) > at sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:292) > at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:385) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) > at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) > at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) > Can't print deadlocks:should not reach here From coleen.phillimore at oracle.com Tue Jan 15 10:59:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Jan 2013 13:59:25 -0500 Subject: RFR: 8005467 CDS size information In-Reply-To: <50EF5319.6010804@oracle.com> References: <50EDB3DA.8010407@oracle.com> <50EDD8A8.7010102@oracle.com> <27BEA167-09B6-4612-9680-6252D1018CC5@oracle.com> <50EE1440.5080609@oracle.com> <50EF5319.6010804@oracle.com> Message-ID: <50F5A70D.7070003@oracle.com> This update looks good to me. Thank you for adding this information, it should be good for analyzing the sizing of the CDS archive file. Coleen On 01/10/2013 06:47 PM, Ioi Lam wrote: > Hi, > > I have updated the patch to use the formats suggested by Coleen and > Christian: > > http://cr.openjdk.java.net/~coleenp/8005467_cdc_size_info_003/ > > Now it looks like: > > ro space: 8687488 [ 40.3% of total] out of 16777216 bytes [51.8% > used] at 0x0000000080000000 > rw space: 11369872 [ 52.7% of total] out of 16777216 bytes [67.8% > used] at 0x0000000081000000 > md space: 1487320 [ 6.9% of total] out of 4194304 bytes [35.5% > used] at 0x0000000082000000 > mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% > used] at 0x0000000082400000 > total : 21578733 [100.0% of total] out of 37871616 bytes [57.0% > used] > > Thanks > - Ioi > > On 01/09/2013 05:07 PM, Coleen Phillimore wrote: >> >> How about "used"? GC uses "used" for such things. >> >> ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% full] >> at 0x0000000080000000. >> >> Thanks, >> Coleen >> >> On 1/9/2013 5:29 PM, Christian Thalinger wrote: >>> On Jan 9, 2013, at 12:52 PM, Ioi Lam wrote: >>> >>>> On 01/09/2013 12:20 PM, Christian Thalinger wrote: >>>>> On Jan 9, 2013, at 10:15 AM, Ioi Lam wrote: >>>>> >>>>>> Please review: >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/8005467_cds_size_info_002/ >>>>>> >>>>>> bug: CDS size information is incorrect and unfriendly >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8005467 >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The printed size information is changed from >>>>>> >>>>>> ro space: 0x000000000014718a out of 0x0000000000200000 words >>>>>> allocated at 0x0000000080000000. >>>>>> rw space: 0x000000000017a6ac out of 0x0000000000200000 words >>>>>> allocated at 0x0000000081000000. >>>>>> md space: 0x0000000000241a70 out of 0x0000000000400000 words >>>>>> allocated at 0x0000000082000000. >>>>>> mc space: 0x0000000000008505 out of 0x000000000001e000 words >>>>>> allocated at 0x0000000082400000. >>>>>> >>>>>> to >>>>>> >>>>>> ro space: 8287312 [39.1% total] out of 16777216 bytes [49.4% >>>>>> full] at 0x0000000080000000. >>>>>> rw space: 11369872 [53.7% total] out of 16777216 bytes [67.8% >>>>>> full] at 0x0000000081000000. >>>>>> md space: 1487248 [ 7.0% total] out of 4194304 bytes [35.5% >>>>>> full] at 0x0000000082000000. >>>>>> mc space: 34053 [ 0.2% total] out of 122880 bytes [27.7% >>>>>> full] at 0x0000000082400000. >>>>> The "% total" and "% full" are confusing. Should this be "% of >>>>> total"? >>>>> >>>>>> total : 21178485 bytes >>>>> This is "total usage", I suppose. Could we also print "total >>>>> allocated size"? >>>> Hi Chris, >>>> >>>> Thanks for the review. Would this be clearer? >>>> >>>> ro space: 8287312 [ 39.1% of total] out of 16777216 bytes [49.4% >>>> occupied] at 0x0000000080000000 >>>> rw space: 11369872 [ 53.7% of total] out of 16777216 bytes [67.8% >>>> occupied] at 0x0000000081000000 >>>> md space: 1487248 [ 7.0% of total] out of 4194304 bytes [35.5% >>>> occupied] at 0x0000000082000000 >>>> mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% >>>> occupied] at 0x0000000082400000 >>>> total : 21178485 [100.0% of total] out of 37871616 bytes [55.9% >>>> occupied] >>> Much better. Thanks. -- Chris >>> >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> -- Chris >>>>> >>>>>> There is otherwise no functional change. >>>>>> >>>>>> >>>>>> Tests run: >>>>>> >>>>>> + JPRT -- to verify build-ability >>>>>> >>>>>> + Manually ran java -Xshare:dump on Linux/Solaris/MacOS/Windows7 >>>>>> (32- and 64-bit VM) to verify the printed output is as expected. >>>>>> >>>>>> Thanks, >>>>>> Ioi >>>>>> >> > From staffan.larsen at oracle.com Tue Jan 15 11:27:19 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Jan 2013 20:27:19 +0100 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F5A56B.6060006@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> <50F5A56B.6060006@oracle.com> Message-ID: <7175F530-A15B-4CCE-8B00-A251100CA77C@oracle.com> On 15 jan 2013, at 19:52, Aleksey Shipilev wrote: > Sorry to hear it. Looking. > Is this a part of regular test suite (which I had missed to run)? No, there are precious few tests for SA (working on adding them). I happened to run into it when looking for something else. /Staffan > > -Aleksey. > > On 01/15/2013 10:43 PM, Staffan Larsen wrote: >> This change seems to have broken deadlock detection in SA. Here is the exception that I get: >> >> java.lang.RuntimeException: should not reach here >> at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) >> >> I haven't yet dug into the details. To reproduce, start any Java program, then run: >> >>> sudo build/linux/linux_amd64_compiler2/jvmg/hotspot -cp build/linux/linux_amd64_compiler2/generated/sa-jdi.jar sun.jvm.hotspot.tools.JStack >> >> Using java runtime at: /home/staffan/java/8latest/jre >> Attaching to process ID 28487, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 25.0-b15-internal-jvmg >> Deadlock Detection: >> >> java.lang.RuntimeException: should not reach here >> at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) >> at sun.jvm.hotspot.oops.Field.(Field.java:47) >> at sun.jvm.hotspot.oops.OopField.(OopField.java:42) >> at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:915) >> at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628) >> at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665) >> at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689) >> at sun.jvm.hotspot.oops.OopUtilities.initThreadFields(OopUtilities.java:220) >> at sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:292) >> at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:385) >> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82) >> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) >> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) >> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) >> Can't print deadlocks:should not reach here > From aleksey.shipilev at oracle.com Tue Jan 15 11:27:52 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 23:27:52 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F5A56B.6060006@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> <50F5A56B.6060006@oracle.com> Message-ID: <50F5ADB8.7010202@oracle.com> And so I built the fresh trunk of hotspot-rt. The path Staffan mentions appears to be some specific launcher, and I don't have that as the part of my regular build with new build system. Hence I assumed running jstack from the built JDK would render the same effect, since it goes through the same deadlock detection code? Suspecting this has something to do with cross-version JDK, picked another victim: $ java -version java version "1.7.0_12-ea" Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b04) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b26, mixed mode) ...and: hotspot-rt-HEAD jstack'ing jdk7u12: OK hotspot-rt-HEAD jstack'ing hotspot-rt-HEAD: OK jdk7u12 jstack'ing jdk7u12: OK jdk7u12 jstack'ing hotspot-rt-HEAD: OK ...hence everything seems to be fine. Staffan, can you clean your build and make the test again? Or, can you publish more thorough steps to reproduce? -Aleksey. On 01/15/2013 10:52 PM, Aleksey Shipilev wrote: > Sorry to hear it. Looking. > Is this a part of regular test suite (which I had missed to run)? > > -Aleksey. > > On 01/15/2013 10:43 PM, Staffan Larsen wrote: >> This change seems to have broken deadlock detection in SA. Here is the exception that I get: >> >> java.lang.RuntimeException: should not reach here >> at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) >> >> I haven't yet dug into the details. To reproduce, start any Java program, then run: >> >>> sudo build/linux/linux_amd64_compiler2/jvmg/hotspot -cp build/linux/linux_amd64_compiler2/generated/sa-jdi.jar sun.jvm.hotspot.tools.JStack >> >> Using java runtime at: /home/staffan/java/8latest/jre >> Attaching to process ID 28487, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 25.0-b15-internal-jvmg >> Deadlock Detection: >> >> java.lang.RuntimeException: should not reach here >> at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) >> at sun.jvm.hotspot.oops.Field.(Field.java:47) >> at sun.jvm.hotspot.oops.OopField.(OopField.java:42) >> at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:915) >> at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628) >> at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665) >> at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689) >> at sun.jvm.hotspot.oops.OopUtilities.initThreadFields(OopUtilities.java:220) >> at sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:292) >> at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:385) >> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82) >> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) >> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) >> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) >> Can't print deadlocks:should not reach here > From erik.helin at oracle.com Tue Jan 15 11:57:40 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 15 Jan 2013 20:57:40 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F59F36.2060306@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> <50F59F36.2060306@oracle.com> Message-ID: <50F5B4B4.1040302@oracle.com> Jesper, On 2013-01-15 19:25, Jesper Wilhelmsson wrote: > I would prefer solution number two for the same reason that I moved my > old gen size fix out of arguments.cpp, the code in Arguments don't know > about generations and if we can avoid adding that knowledge I think we > should avoid it. CollectorPolicy already know about generations and I > think it is the right place for this code. I saw that you updated to your webrev directly after sending my email. I'm think that our changes should be consistent, and therefore I would prefer option 2 (putting the code in CollectorPolicy::initialize_flags). Jon, what do you think? > /Jesper > > > On 15/1/13 3:45 PM, Erik Helin wrote: >> Jon, >> >> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>> Change looks good. >> >> Thanks! >> >> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>> Do you think it would >>> fit better in TwoGenCollectorPolicy::initialize_flags() >>> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >>> add it also to G1CollectorPolicy::initialize_flags() >>> or do some refactoring of the various initialize_flags(). >> >> I don't want to duplicate the code by adding it to both >> G1CollectorPolicy and GenCollectorPolicy, but I agree that >> Arguments::set_heap_size might not be the best place for it. >> >> I've tried a few different approaches, and also discussed with Bengt >> and Jesper, and I think that one of the following approaches is the >> way to go: >> >> 1. Add a new function, Arguments::set_heap_generation_sizes(), that >> sets MaxNewSize. Jesper could add his code for OldSize in this >> function as well. >> >> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ >> >> 2. Add the code to CollectorPolicy::initialize_flags(). >> >> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ >> >> Both options have drawbacks: >> >> It does not feel right to add a function to arguments.cpp that handles >> GC specific flags. On the other hand, this has already been done quite >> extensively, but that is not an excuse for continue doing it. >> >> Adding the code to CollectorPolicy breaks the abstraction that >> CollectorPolicy is not supposed to know about generational heap >> collectors (although this has already happened, see >> CollectorPolicy::initialize_size_info). >> >> Out of these two, I would prefer the first option (adding a new >> function in arguments.cpp) and I think both options are better than >> duplicating the code. >> >> Which option do you prefer? Or would you prefer another solution? >> >> Thanks, >> Erik >> >>> Jon >>> >>> >>> On 01/12/13 00:27, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change sets MaxNewSize to always be less than or equal to >>>> MaxHeapSize. The current default value is max_uintx. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>>> >>>> RFE: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>>> >>>> Analysis: >>>> The change should not affect the existing code. The case that has to >>>> be analyzed is when MaxNewSize is not set on the command line, since >>>> the update of MaxNewSize is guarded by "if >>>> (FLAG_IS_DEFAULT(MaxNewSize))". >>>> >>>> MaxNewSize is only used in the following files: >>>> >>>> - g1CollectorPolicy.cpp: >>>> Guards all the usage of MaxNewSize in if statements: >>>> >>>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>>> ... >>>> } >>>> >>>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>>> this code path. >>>> >>>> - arguments.cpp: >>>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>>> Otherwise, only writes new values to MaxNewSize that are not based on >>>> the value of MaxNewSize. This code is not affected since the value of >>>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>>> >>>> - collectorPolicy.cpp: >>>> MaxNewSize is used in a couple of places: >>>> >>>> if (NewSize > MaxNewSize) { >>>> MaxNewSize = NewSize; >>>> } >>>> >>>> If both NewSize and MaxNewSize have their default values, then >>>> NewSize is ScaleForWordSize(1*M) which will always be less than >>>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>>> statement is only changed if NewSize is set on the command line to a >>>> value larger than MaxHeapSize, which is not a valid case. >>>> >>>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>>> ... >>>> } else { >>>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>>> } >>>> >>>> This "if" check will still follow the "else" branch in the default >>>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>>> The semantics of the calculation in the else branch is also preserved, >>>> since MAX2(max_new_size, NewSize) will still always be less than >>>> MaxNewSize for all valid values of NewSize. >>>> >>>> Testing: >>>> Before the change: >>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>> uintx MaxHeapSize := 2017460224 {product} >>>> uintx MaxNewSize = 18446744073709486080 {product} >>>> >>>> After the change: >>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>> uintx MaxHeapSize := 2017460224 {product} >>>> uintx MaxNewSize = 2015428608 {product} >>>> >>>> JPRT >>>> >>>> Thanks, >>>> Erik >> > From staffan.larsen at oracle.com Tue Jan 15 12:47:15 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Jan 2013 21:47:15 +0100 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F5ADB8.7010202@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> <50F5A56B.6060006@oracle.com> <50F5ADB8.7010202@oracle.com> Message-ID: <88C6FC04-4B0C-41E5-A20E-E66FB3A8AAF0@oracle.com> The the specific launcher is only available if you build just hotspot (which I think most hotspot developers still do). If you run the jstack launcher from the jdk bin directory you have to run with the -F flag to use the SA version of jstack. Normally it uses code in Hotspot to do deadlock detection and print stacktraces. /Staffan On 15 jan 2013, at 20:27, Aleksey Shipilev wrote: > And so I built the fresh trunk of hotspot-rt. > > The path Staffan mentions appears to be some specific launcher, and I > don't have that as the part of my regular build with new build system. > Hence I assumed running jstack from the built JDK would render the same > effect, since it goes through the same deadlock detection code? > > Suspecting this has something to do with cross-version JDK, picked > another victim: > > $ java -version > java version "1.7.0_12-ea" > Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b04) > Java HotSpot(TM) 64-Bit Server VM (build 24.0-b26, mixed mode) > > ...and: > > hotspot-rt-HEAD jstack'ing jdk7u12: OK > hotspot-rt-HEAD jstack'ing hotspot-rt-HEAD: OK > jdk7u12 jstack'ing jdk7u12: OK > jdk7u12 jstack'ing hotspot-rt-HEAD: OK > > ...hence everything seems to be fine. Staffan, can you clean your build > and make the test again? Or, can you publish more thorough steps to > reproduce? > > -Aleksey. > > On 01/15/2013 10:52 PM, Aleksey Shipilev wrote: >> Sorry to hear it. Looking. >> Is this a part of regular test suite (which I had missed to run)? >> >> -Aleksey. >> >> On 01/15/2013 10:43 PM, Staffan Larsen wrote: >>> This change seems to have broken deadlock detection in SA. Here is the exception that I get: >>> >>> java.lang.RuntimeException: should not reach here >>> at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) >>> >>> I haven't yet dug into the details. To reproduce, start any Java program, then run: >>> >>>> sudo build/linux/linux_amd64_compiler2/jvmg/hotspot -cp build/linux/linux_amd64_compiler2/generated/sa-jdi.jar sun.jvm.hotspot.tools.JStack >>> >>> Using java runtime at: /home/staffan/java/8latest/jre >>> Attaching to process ID 28487, please wait... >>> Debugger attached successfully. >>> Server compiler detected. >>> JVM version is 25.0-b15-internal-jvmg >>> Deadlock Detection: >>> >>> java.lang.RuntimeException: should not reach here >>> at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) >>> at sun.jvm.hotspot.oops.Field.(Field.java:47) >>> at sun.jvm.hotspot.oops.OopField.(OopField.java:42) >>> at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:915) >>> at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628) >>> at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665) >>> at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689) >>> at sun.jvm.hotspot.oops.OopUtilities.initThreadFields(OopUtilities.java:220) >>> at sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:292) >>> at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:385) >>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82) >>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52) >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>> at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) >>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) >>> at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) >>> Can't print deadlocks:should not reach here >> > From jon.masamitsu at oracle.com Tue Jan 15 16:07:21 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Jan 2013 16:07:21 -0800 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F56B7E.3070406@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> Message-ID: <50F5EF39.3050808@oracle.com> Erik, I'd prefer option 2) to get it closer to the code that knows about generations. I agree that CollectorPolicy::initialize_size_info() is broken and duplicating the code would be the worst. I'm guessing that the current G1CollectorPolicy doesn't derive from GenCollectorPolicy because G1 was not exclusively generational until recently. Would you consider fixing G1CollectorPolicy to derive from GenCollectorPolicy so that you could add the code to GenCollectorPolicy::initialize_flags()? If you're touching code and think it is ugly, I think you have license to fix it. Thanks. Jon On 01/15/13 06:45, Erik Helin wrote: > Jon, > > On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >> Change looks good. > > Thanks! > > On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >> Do you think it would >> fit better in TwoGenCollectorPolicy::initialize_flags() >> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >> add it also to G1CollectorPolicy::initialize_flags() >> or do some refactoring of the various initialize_flags(). > > I don't want to duplicate the code by adding it to both > G1CollectorPolicy and GenCollectorPolicy, but I agree that > Arguments::set_heap_size might not be the best place for it. > > I've tried a few different approaches, and also discussed with Bengt > and Jesper, and I think that one of the following approaches is the > way to go: > > 1. Add a new function, Arguments::set_heap_generation_sizes(), that > sets MaxNewSize. Jesper could add his code for OldSize in this > function as well. > > Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ > > 2. Add the code to CollectorPolicy::initialize_flags(). > > Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ > > Both options have drawbacks: > > It does not feel right to add a function to arguments.cpp that handles > GC specific flags. On the other hand, this has already been done quite > extensively, but that is not an excuse for continue doing it. > > Adding the code to CollectorPolicy breaks the abstraction that > CollectorPolicy is not supposed to know about generational heap > collectors (although this has already happened, see > CollectorPolicy::initialize_size_info). > > Out of these two, I would prefer the first option (adding a new > function in arguments.cpp) and I think both options are better than > duplicating the code. > > Which option do you prefer? Or would you prefer another solution? > > Thanks, > Erik > >> Jon >> >> >> On 01/12/13 00:27, Erik Helin wrote: >>> Hi all, >>> >>> this change sets MaxNewSize to always be less than or equal to >>> MaxHeapSize. The current default value is max_uintx. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>> >>> RFE: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>> >>> Analysis: >>> The change should not affect the existing code. The case that has to >>> be analyzed is when MaxNewSize is not set on the command line, since >>> the update of MaxNewSize is guarded by "if >>> (FLAG_IS_DEFAULT(MaxNewSize))". >>> >>> MaxNewSize is only used in the following files: >>> >>> - g1CollectorPolicy.cpp: >>> Guards all the usage of MaxNewSize in if statements: >>> >>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>> ... >>> } >>> >>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>> this code path. >>> >>> - arguments.cpp: >>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>> Otherwise, only writes new values to MaxNewSize that are not based on >>> the value of MaxNewSize. This code is not affected since the value of >>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>> >>> - collectorPolicy.cpp: >>> MaxNewSize is used in a couple of places: >>> >>> if (NewSize > MaxNewSize) { >>> MaxNewSize = NewSize; >>> } >>> >>> If both NewSize and MaxNewSize have their default values, then >>> NewSize is ScaleForWordSize(1*M) which will always be less than >>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>> statement is only changed if NewSize is set on the command line to a >>> value larger than MaxHeapSize, which is not a valid case. >>> >>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>> ... >>> } else { >>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>> } >>> >>> This "if" check will still follow the "else" branch in the default >>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>> The semantics of the calculation in the else branch is also >>> preserved, >>> since MAX2(max_new_size, NewSize) will still always be less than >>> MaxNewSize for all valid values of NewSize. >>> >>> Testing: >>> Before the change: >>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>> uintx MaxHeapSize := 2017460224 {product} >>> uintx MaxNewSize = 18446744073709486080 {product} >>> >>> After the change: >>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>> uintx MaxHeapSize := 2017460224 {product} >>> uintx MaxNewSize = 2015428608 {product} >>> >>> JPRT >>> >>> Thanks, >>> Erik > From jon.masamitsu at oracle.com Tue Jan 15 16:10:24 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Jan 2013 16:10:24 -0800 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F5B4B4.1040302@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> <50F59F36.2060306@oracle.com> <50F5B4B4.1040302@oracle.com> Message-ID: <50F5EFF0.5060203@oracle.com> On 01/15/13 11:57, Erik Helin wrote: > Jesper, > > On 2013-01-15 19:25, Jesper Wilhelmsson wrote: >> I would prefer solution number two for the same reason that I moved my >> old gen size fix out of arguments.cpp, the code in Arguments don't know >> about generations and if we can avoid adding that knowledge I think we >> should avoid it. CollectorPolicy already know about generations and I >> think it is the right place for this code. > > I saw that you updated to your webrev directly after sending my email. > I'm think that our changes should be consistent, and therefore I would > prefer option 2 (putting the code in CollectorPolicy::initialize_flags). > > Jon, what do you think? Yes, option to is my preference. Jon > >> /Jesper >> >> >> On 15/1/13 3:45 PM, Erik Helin wrote: >>> Jon, >>> >>> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>>> Change looks good. >>> >>> Thanks! >>> >>> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>>> Do you think it would >>>> fit better in TwoGenCollectorPolicy::initialize_flags() >>>> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >>>> add it also to G1CollectorPolicy::initialize_flags() >>>> or do some refactoring of the various initialize_flags(). >>> >>> I don't want to duplicate the code by adding it to both >>> G1CollectorPolicy and GenCollectorPolicy, but I agree that >>> Arguments::set_heap_size might not be the best place for it. >>> >>> I've tried a few different approaches, and also discussed with Bengt >>> and Jesper, and I think that one of the following approaches is the >>> way to go: >>> >>> 1. Add a new function, Arguments::set_heap_generation_sizes(), that >>> sets MaxNewSize. Jesper could add his code for OldSize in this >>> function as well. >>> >>> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ >>> >>> 2. Add the code to CollectorPolicy::initialize_flags(). >>> >>> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ >>> >>> Both options have drawbacks: >>> >>> It does not feel right to add a function to arguments.cpp that handles >>> GC specific flags. On the other hand, this has already been done quite >>> extensively, but that is not an excuse for continue doing it. >>> >>> Adding the code to CollectorPolicy breaks the abstraction that >>> CollectorPolicy is not supposed to know about generational heap >>> collectors (although this has already happened, see >>> CollectorPolicy::initialize_size_info). >>> >>> Out of these two, I would prefer the first option (adding a new >>> function in arguments.cpp) and I think both options are better than >>> duplicating the code. >>> >>> Which option do you prefer? Or would you prefer another solution? >>> >>> Thanks, >>> Erik >>> >>>> Jon >>>> >>>> >>>> On 01/12/13 00:27, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this change sets MaxNewSize to always be less than or equal to >>>>> MaxHeapSize. The current default value is max_uintx. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>>>> >>>>> RFE: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>>>> >>>>> Analysis: >>>>> The change should not affect the existing code. The case that has to >>>>> be analyzed is when MaxNewSize is not set on the command line, since >>>>> the update of MaxNewSize is guarded by "if >>>>> (FLAG_IS_DEFAULT(MaxNewSize))". >>>>> >>>>> MaxNewSize is only used in the following files: >>>>> >>>>> - g1CollectorPolicy.cpp: >>>>> Guards all the usage of MaxNewSize in if statements: >>>>> >>>>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>>>> ... >>>>> } >>>>> >>>>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>>>> this code path. >>>>> >>>>> - arguments.cpp: >>>>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>>>> Otherwise, only writes new values to MaxNewSize that are not based on >>>>> the value of MaxNewSize. This code is not affected since the value of >>>>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>>>> >>>>> - collectorPolicy.cpp: >>>>> MaxNewSize is used in a couple of places: >>>>> >>>>> if (NewSize > MaxNewSize) { >>>>> MaxNewSize = NewSize; >>>>> } >>>>> >>>>> If both NewSize and MaxNewSize have their default values, then >>>>> NewSize is ScaleForWordSize(1*M) which will always be less than >>>>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>>>> statement is only changed if NewSize is set on the command line to a >>>>> value larger than MaxHeapSize, which is not a valid case. >>>>> >>>>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>>>> ... >>>>> } else { >>>>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>>>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>>>> } >>>>> >>>>> This "if" check will still follow the "else" branch in the default >>>>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>>>> The semantics of the calculation in the else branch is also >>>>> preserved, >>>>> since MAX2(max_new_size, NewSize) will still always be less than >>>>> MaxNewSize for all valid values of NewSize. >>>>> >>>>> Testing: >>>>> Before the change: >>>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>>> uintx MaxHeapSize := 2017460224 {product} >>>>> uintx MaxNewSize = 18446744073709486080 {product} >>>>> >>>>> After the change: >>>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>>> uintx MaxHeapSize := 2017460224 {product} >>>>> uintx MaxNewSize = 2015428608 {product} >>>>> >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Erik >>> >> From jon.masamitsu at oracle.com Tue Jan 15 16:11:39 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Jan 2013 16:11:39 -0800 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F5B4B4.1040302@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> <50F59F36.2060306@oracle.com> <50F5B4B4.1040302@oracle.com> Message-ID: <50F5F03B.8010608@oracle.com> On 01/15/13 11:57, Erik Helin wrote: > Jesper, > > On 2013-01-15 19:25, Jesper Wilhelmsson wrote: >> I would prefer solution number two for the same reason that I moved my >> old gen size fix out of arguments.cpp, the code in Arguments don't know >> about generations and if we can avoid adding that knowledge I think we >> should avoid it. CollectorPolicy already know about generations and I >> think it is the right place for this code. > > I saw that you updated to your webrev directly after sending my email. > I'm think that our changes should be consistent, and therefore I would > prefer option 2 (putting the code in CollectorPolicy::initialize_flags). > > Jon, what do you think? Yes to option 2. Jon > >> /Jesper >> >> >> On 15/1/13 3:45 PM, Erik Helin wrote: >>> Jon, >>> >>> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>>> Change looks good. >>> >>> Thanks! >>> >>> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>>> Do you think it would >>>> fit better in TwoGenCollectorPolicy::initialize_flags() >>>> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >>>> add it also to G1CollectorPolicy::initialize_flags() >>>> or do some refactoring of the various initialize_flags(). >>> >>> I don't want to duplicate the code by adding it to both >>> G1CollectorPolicy and GenCollectorPolicy, but I agree that >>> Arguments::set_heap_size might not be the best place for it. >>> >>> I've tried a few different approaches, and also discussed with Bengt >>> and Jesper, and I think that one of the following approaches is the >>> way to go: >>> >>> 1. Add a new function, Arguments::set_heap_generation_sizes(), that >>> sets MaxNewSize. Jesper could add his code for OldSize in this >>> function as well. >>> >>> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ >>> >>> 2. Add the code to CollectorPolicy::initialize_flags(). >>> >>> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ >>> >>> Both options have drawbacks: >>> >>> It does not feel right to add a function to arguments.cpp that handles >>> GC specific flags. On the other hand, this has already been done quite >>> extensively, but that is not an excuse for continue doing it. >>> >>> Adding the code to CollectorPolicy breaks the abstraction that >>> CollectorPolicy is not supposed to know about generational heap >>> collectors (although this has already happened, see >>> CollectorPolicy::initialize_size_info). >>> >>> Out of these two, I would prefer the first option (adding a new >>> function in arguments.cpp) and I think both options are better than >>> duplicating the code. >>> >>> Which option do you prefer? Or would you prefer another solution? >>> >>> Thanks, >>> Erik >>> >>>> Jon >>>> >>>> >>>> On 01/12/13 00:27, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this change sets MaxNewSize to always be less than or equal to >>>>> MaxHeapSize. The current default value is max_uintx. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>>>> >>>>> RFE: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>>>> >>>>> Analysis: >>>>> The change should not affect the existing code. The case that has to >>>>> be analyzed is when MaxNewSize is not set on the command line, since >>>>> the update of MaxNewSize is guarded by "if >>>>> (FLAG_IS_DEFAULT(MaxNewSize))". >>>>> >>>>> MaxNewSize is only used in the following files: >>>>> >>>>> - g1CollectorPolicy.cpp: >>>>> Guards all the usage of MaxNewSize in if statements: >>>>> >>>>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>>>> ... >>>>> } >>>>> >>>>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>>>> this code path. >>>>> >>>>> - arguments.cpp: >>>>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>>>> Otherwise, only writes new values to MaxNewSize that are not based on >>>>> the value of MaxNewSize. This code is not affected since the value of >>>>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>>>> >>>>> - collectorPolicy.cpp: >>>>> MaxNewSize is used in a couple of places: >>>>> >>>>> if (NewSize > MaxNewSize) { >>>>> MaxNewSize = NewSize; >>>>> } >>>>> >>>>> If both NewSize and MaxNewSize have their default values, then >>>>> NewSize is ScaleForWordSize(1*M) which will always be less than >>>>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>>>> statement is only changed if NewSize is set on the command line to a >>>>> value larger than MaxHeapSize, which is not a valid case. >>>>> >>>>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>>>> ... >>>>> } else { >>>>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>>>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>>>> } >>>>> >>>>> This "if" check will still follow the "else" branch in the default >>>>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>>>> The semantics of the calculation in the else branch is also >>>>> preserved, >>>>> since MAX2(max_new_size, NewSize) will still always be less than >>>>> MaxNewSize for all valid values of NewSize. >>>>> >>>>> Testing: >>>>> Before the change: >>>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>>> uintx MaxHeapSize := 2017460224 {product} >>>>> uintx MaxNewSize = 18446744073709486080 {product} >>>>> >>>>> After the change: >>>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>>> uintx MaxHeapSize := 2017460224 {product} >>>>> uintx MaxNewSize = 2015428608 {product} >>>>> >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Erik >>> >> From staffan.larsen at oracle.com Tue Jan 15 22:37:40 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 16 Jan 2013 06:37:40 +0000 Subject: hg: hsx/hsx24/hotspot: 8005849: JEP 167: Event-Based JVM Tracing Message-ID: <20130116063750.A590E472C9@hg.openjdk.java.net> Changeset: bb74dc5ddf07 Author: sla Date: 2013-01-15 09:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bb74dc5ddf07 8005849: JEP 167: Event-Based JVM Tracing Reviewed-by: acorn, coleenp Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova ! make/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/top.make + make/bsd/makefiles/trace.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/top.make + make/linux/makefiles/trace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/top.make + make/solaris/makefiles/trace.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/generated.make ! make/windows/makefiles/projectcreator.make + make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/x86/vm/frame_x86.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_share_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp + src/share/vm/gc_implementation/g1/g1YCTypes.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.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.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp + src/share/vm/gc_implementation/shared/gcHeapSummary.hpp + src/share/vm/gc_implementation/shared/gcTimer.cpp + src/share/vm/gc_implementation/shared/gcTimer.hpp + src/share/vm/gc_implementation/shared/gcTrace.cpp + src/share/vm/gc_implementation/shared/gcTrace.hpp + src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.hpp + src/share/vm/gc_implementation/shared/gcWhen.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp + src/share/vm/gc_implementation/shared/promotionFailedInfo.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp + src/share/vm/gc_interface/gcName.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp + src/share/vm/memory/referenceProcessorStats.hpp + src/share/vm/memory/referenceType.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp + src/share/vm/opto/phasetype.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGen.java ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/memBaseline.cpp + src/share/vm/trace/trace.dtd + src/share/vm/trace/trace.xml + src/share/vm/trace/traceBackend.hpp + src/share/vm/trace/traceDataTypes.hpp + src/share/vm/trace/traceEvent.hpp + src/share/vm/trace/traceEventClasses.xsl + src/share/vm/trace/traceEventIds.xsl - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/traceStream.hpp + src/share/vm/trace/traceTime.hpp + src/share/vm/trace/traceTypes.xsl + src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/tracing.hpp + src/share/vm/trace/xinclude.mod + src/share/vm/trace/xsl_util.xsl ! src/share/vm/utilities/globalDefinitions.hpp From erik.helin at oracle.com Tue Jan 15 23:23:43 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Jan 2013 08:23:43 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F5EF39.3050808@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> <50F5EF39.3050808@oracle.com> Message-ID: <50F6557F.5040508@oracle.com> John, On 01/16/2013 01:07 AM, Jon Masamitsu wrote: > Would you consider fixing G1CollectorPolicy > to derive from GenCollectorPolicy so that you could > add the code to GenCollectorPolicy::initialize_flags()? I agree that the CollectorPolicy inheritance hierarchy needs to be fixed, but I don't think that it should be part of this change. I can file an RFE and see if I can get some time work on it. Thanks, Erik > > Thanks. > > Jon > > > On 01/15/13 06:45, Erik Helin wrote: >> Jon, >> >> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>> Change looks good. >> >> Thanks! >> >> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>> Do you think it would >>> fit better in TwoGenCollectorPolicy::initialize_flags() >>> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >>> add it also to G1CollectorPolicy::initialize_flags() >>> or do some refactoring of the various initialize_flags(). >> >> I don't want to duplicate the code by adding it to both >> G1CollectorPolicy and GenCollectorPolicy, but I agree that >> Arguments::set_heap_size might not be the best place for it. >> >> I've tried a few different approaches, and also discussed with Bengt >> and Jesper, and I think that one of the following approaches is the >> way to go: >> >> 1. Add a new function, Arguments::set_heap_generation_sizes(), that >> sets MaxNewSize. Jesper could add his code for OldSize in this >> function as well. >> >> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ >> >> 2. Add the code to CollectorPolicy::initialize_flags(). >> >> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ >> >> Both options have drawbacks: >> >> It does not feel right to add a function to arguments.cpp that handles >> GC specific flags. On the other hand, this has already been done quite >> extensively, but that is not an excuse for continue doing it. >> >> Adding the code to CollectorPolicy breaks the abstraction that >> CollectorPolicy is not supposed to know about generational heap >> collectors (although this has already happened, see >> CollectorPolicy::initialize_size_info). >> >> Out of these two, I would prefer the first option (adding a new >> function in arguments.cpp) and I think both options are better than >> duplicating the code. >> >> Which option do you prefer? Or would you prefer another solution? >> >> Thanks, >> Erik >> >>> Jon >>> >>> >>> On 01/12/13 00:27, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change sets MaxNewSize to always be less than or equal to >>>> MaxHeapSize. The current default value is max_uintx. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>>> >>>> RFE: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>>> >>>> Analysis: >>>> The change should not affect the existing code. The case that has to >>>> be analyzed is when MaxNewSize is not set on the command line, since >>>> the update of MaxNewSize is guarded by "if >>>> (FLAG_IS_DEFAULT(MaxNewSize))". >>>> >>>> MaxNewSize is only used in the following files: >>>> >>>> - g1CollectorPolicy.cpp: >>>> Guards all the usage of MaxNewSize in if statements: >>>> >>>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>>> ... >>>> } >>>> >>>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>>> this code path. >>>> >>>> - arguments.cpp: >>>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>>> Otherwise, only writes new values to MaxNewSize that are not based on >>>> the value of MaxNewSize. This code is not affected since the value of >>>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>>> >>>> - collectorPolicy.cpp: >>>> MaxNewSize is used in a couple of places: >>>> >>>> if (NewSize > MaxNewSize) { >>>> MaxNewSize = NewSize; >>>> } >>>> >>>> If both NewSize and MaxNewSize have their default values, then >>>> NewSize is ScaleForWordSize(1*M) which will always be less than >>>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>>> statement is only changed if NewSize is set on the command line to a >>>> value larger than MaxHeapSize, which is not a valid case. >>>> >>>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>>> ... >>>> } else { >>>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>>> } >>>> >>>> This "if" check will still follow the "else" branch in the default >>>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>>> The semantics of the calculation in the else branch is also >>>> preserved, >>>> since MAX2(max_new_size, NewSize) will still always be less than >>>> MaxNewSize for all valid values of NewSize. >>>> >>>> Testing: >>>> Before the change: >>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>> uintx MaxHeapSize := 2017460224 {product} >>>> uintx MaxNewSize = 18446744073709486080 {product} >>>> >>>> After the change: >>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>> uintx MaxHeapSize := 2017460224 {product} >>>> uintx MaxNewSize = 2015428608 {product} >>>> >>>> JPRT >>>> >>>> Thanks, >>>> Erik >> From erik.helin at oracle.com Tue Jan 15 23:26:48 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Jan 2013 08:26:48 +0100 Subject: RFR (S): 8005989: The default value for MaxNewSize should be less than or equal to MaxHeapSize In-Reply-To: <50F5F03B.8010608@oracle.com> References: <50F11E8C.5070302@oracle.com> <50F46D78.5050306@oracle.com> <50F56B7E.3070406@oracle.com> <50F59F36.2060306@oracle.com> <50F5B4B4.1040302@oracle.com> <50F5F03B.8010608@oracle.com> Message-ID: <50F65638.8010009@oracle.com> John and Jesper, On 01/16/2013 01:11 AM, Jon Masamitsu wrote: > On 01/15/13 11:57, Erik Helin wrote: >> On 2013-01-15 19:25, Jesper Wilhelmsson wrote: >>> I would prefer solution number two for the same reason that I moved my >>> old gen size fix out of arguments.cpp, the code in Arguments don't know >>> about generations and if we can avoid adding that knowledge I think we >>> should avoid it. CollectorPolicy already know about generations and I >>> think it is the right place for this code. >> >> Jon, what do you think? > > Yes to option 2. Ok, then I will commit option 2. Thanks for reviewing this code! Erik > Jon >> >>> /Jesper >>> >>> >>> On 15/1/13 3:45 PM, Erik Helin wrote: >>>> Jon, >>>> >>>> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>>>> Change looks good. >>>> >>>> Thanks! >>>> >>>> On 01/14/2013 09:41 PM, Jon Masamitsu wrote: >>>>> Do you think it would >>>>> fit better in TwoGenCollectorPolicy::initialize_flags() >>>>> or maybe GenCollectorPolicy::initialize_flags()? You'd have to >>>>> add it also to G1CollectorPolicy::initialize_flags() >>>>> or do some refactoring of the various initialize_flags(). >>>> >>>> I don't want to duplicate the code by adding it to both >>>> G1CollectorPolicy and GenCollectorPolicy, but I agree that >>>> Arguments::set_heap_size might not be the best place for it. >>>> >>>> I've tried a few different approaches, and also discussed with Bengt >>>> and Jesper, and I think that one of the following approaches is the >>>> way to go: >>>> >>>> 1. Add a new function, Arguments::set_heap_generation_sizes(), that >>>> sets MaxNewSize. Jesper could add his code for OldSize in this >>>> function as well. >>>> >>>> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.01/ >>>> >>>> 2. Add the code to CollectorPolicy::initialize_flags(). >>>> >>>> Webrev: http://cr.openjdk.java.net/~ehelin/8005989/webrev.02/ >>>> >>>> Both options have drawbacks: >>>> >>>> It does not feel right to add a function to arguments.cpp that handles >>>> GC specific flags. On the other hand, this has already been done quite >>>> extensively, but that is not an excuse for continue doing it. >>>> >>>> Adding the code to CollectorPolicy breaks the abstraction that >>>> CollectorPolicy is not supposed to know about generational heap >>>> collectors (although this has already happened, see >>>> CollectorPolicy::initialize_size_info). >>>> >>>> Out of these two, I would prefer the first option (adding a new >>>> function in arguments.cpp) and I think both options are better than >>>> duplicating the code. >>>> >>>> Which option do you prefer? Or would you prefer another solution? >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Jon >>>>> >>>>> >>>>> On 01/12/13 00:27, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this change sets MaxNewSize to always be less than or equal to >>>>>> MaxHeapSize. The current default value is max_uintx. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ehelin/8005989/webrev.00/ >>>>>> >>>>>> RFE: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005989 >>>>>> >>>>>> Analysis: >>>>>> The change should not affect the existing code. The case that has to >>>>>> be analyzed is when MaxNewSize is not set on the command line, since >>>>>> the update of MaxNewSize is guarded by "if >>>>>> (FLAG_IS_DEFAULT(MaxNewSize))". >>>>>> >>>>>> MaxNewSize is only used in the following files: >>>>>> >>>>>> - g1CollectorPolicy.cpp: >>>>>> Guards all the usage of MaxNewSize in if statements: >>>>>> >>>>>> if (FLAG_IS_CMDLINE(MaxNewSize)) { >>>>>> ... >>>>>> } >>>>>> >>>>>> Since this change uses FLAG_SET_DEFAULT, this change won't affect >>>>>> this code path. >>>>>> >>>>>> - arguments.cpp: >>>>>> Only reads MaxNewSize in FLAG_IS_DEFAULT(MaxNewSize) statements. >>>>>> Otherwise, only writes new values to MaxNewSize that are not based on >>>>>> the value of MaxNewSize. This code is not affected since the value of >>>>>> FLAG_IS_DEFAULT(MaxNewSize) is not affected. >>>>>> >>>>>> - collectorPolicy.cpp: >>>>>> MaxNewSize is used in a couple of places: >>>>>> >>>>>> if (NewSize > MaxNewSize) { >>>>>> MaxNewSize = NewSize; >>>>>> } >>>>>> >>>>>> If both NewSize and MaxNewSize have their default values, then >>>>>> NewSize is ScaleForWordSize(1*M) which will always be less than >>>>>> MaxNewSize which now is MaxHeapSize. The semantics of the if >>>>>> statement is only changed if NewSize is set on the command line to a >>>>>> value larger than MaxHeapSize, which is not a valid case. >>>>>> >>>>>> if (FLAG_IS_CMDLINE(MaxNewSize) || FLAG_IS_ERGO(MaxNewSize) { >>>>>> ... >>>>>> } else { >>>>>> max_new_size = scale_by_NewRatio_aligned(max_heap_byte_size()); >>>>>> max_new_size = MIN2(MAX2(max_new_size, NewSize), MaxNewSize); >>>>>> } >>>>>> >>>>>> This "if" check will still follow the "else" branch in the default >>>>>> case, just as before, since FLAG_SET_DEFAULT is used in this change. >>>>>> The semantics of the calculation in the else branch is also >>>>>> preserved, >>>>>> since MAX2(max_new_size, NewSize) will still always be less than >>>>>> MaxNewSize for all valid values of NewSize. >>>>>> >>>>>> Testing: >>>>>> Before the change: >>>>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>>>> uintx MaxHeapSize := 2017460224 {product} >>>>>> uintx MaxNewSize = 18446744073709486080 {product} >>>>>> >>>>>> After the change: >>>>>> java -XX:+PrintFlagsFinal -version | grep 'MaxHeapSize \| MaxNewSize' >>>>>> uintx MaxHeapSize := 2017460224 {product} >>>>>> uintx MaxNewSize = 2015428608 {product} >>>>>> >>>>>> JPRT >>>>>> >>>>>> Thanks, >>>>>> Erik >>>> >>> From aleksey.shipilev at oracle.com Wed Jan 16 00:52:04 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 12:52:04 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <88C6FC04-4B0C-41E5-A20E-E66FB3A8AAF0@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> <50F5A56B.6060006@oracle.com> <50F5ADB8.7010202@oracle.com> <88C6FC04-4B0C-41E5-A20E-E66FB3A8AAF0@oracle.com> Message-ID: <50F66A34.7030401@oracle.com> On 01/16/2013 12:47 AM, Staffan Larsen wrote: > The the specific launcher is only available if you build just hotspot > (which I think most hotspot developers still do). And which is unfortunate since there is no lingua franca in builds. Also, I wandered around openjdk.java.net looking for instructions to build HotSpot separately, but found none. Any hints? > If you run the jstack launcher from the jdk bin directory you have to > run with the -F flag to use the SA version of jstack. Normally it > uses code in Hotspot to do deadlock detection and print > stacktraces. Ok, I see, thanks. "jstack -F" fails on all combinations, including jdk7u12-ea vs. jdk7u12-ea with: Attaching to process ID 20721, please wait... Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process I will be glad to follow up on this, if only I could reproduce this locally. Is there something else should be enabled to reproduce this? -Aleksey. From staffan.larsen at oracle.com Wed Jan 16 01:07:18 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Jan 2013 10:07:18 +0100 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <50F66A34.7030401@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> <50F5A56B.6060006@oracle.com> <50F5ADB8.7010202@oracle.com> <88C6FC04-4B0C-41E5-A20E-E66FB3A8AAF0@oracle.com> <50F66A34.7030401@oracle.com> Message-ID: <11E624DE-94D5-47BF-9A2A-7FC3F30EDD7A@oracle.com> On 16 jan 2013, at 09:52, Aleksey Shipilev wrote: > On 01/16/2013 12:47 AM, Staffan Larsen wrote: >> The the specific launcher is only available if you build just hotspot >> (which I think most hotspot developers still do). > > And which is unfortunate since there is no lingua franca in builds. Things suck until they become better. ;) > Also, I wandered around openjdk.java.net looking for instructions to > build HotSpot separately, but found none. Any hints? Here is how I build: > cd make > make ALT_BOOTDIR= ARCH_DATA_MODEL=64 [jvmg | product | fastdebug] > >> If you run the jstack launcher from the jdk bin directory you have to >> run with the -F flag to use the SA version of jstack. Normally it >> uses code in Hotspot to do deadlock detection and print >> stacktraces. > > Ok, I see, thanks. "jstack -F" fails on all combinations, including > jdk7u12-ea vs. jdk7u12-ea with: > > Attaching to process ID 20721, please wait... > Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: > Can't attach to the process > > I will be glad to follow up on this, if only I could reproduce this > locally. Is there something else should be enabled to reproduce this? It needs to be run as root to be able to attach to the process as a debugger. /Staffan > > -Aleksey. From aleksey.shipilev at oracle.com Wed Jan 16 01:18:04 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 13:18:04 +0400 Subject: RFR (M) #5 CR 8003985: Support @Contended annotation In-Reply-To: <11E624DE-94D5-47BF-9A2A-7FC3F30EDD7A@oracle.com> References: <50EEDB43.1050803@oracle.com> <50EF4B8A.6050909@oracle.com> <50EF4CA9.6040800@oracle.com> <50F06963.7070809@oracle.com> <50F07D82.1050105@oracle.com> <50F08DCE.1060907@oracle.com> <50F09C15.5090501@oracle.com> <50F0A2DF.8070003@oracle.com> <50F0A48B.4040609@oracle.com> <50F0A82E.8090204@oracle.com> <81E1F01F-A532-45B5-A112-752D58E0C64A@oracle.com> <50F5A56B.6060006@oracle.com> <50F5ADB8.7010202@oracle.com> <88C6FC04-4B0C-41E5-A20E-E66FB3A8AAF0@oracle.com> <50F66A34.7030401@oracle.com> <11E624DE-94D5-47BF-9A2A-7FC3F30EDD7A@oracle.com> Message-ID: <50F6704C.10609@oracle.com> On 01/16/2013 01:07 PM, Staffan Larsen wrote: >>> If you run the jstack launcher from the jdk bin directory you have to >>> run with the -F flag to use the SA version of jstack. Normally it >>> uses code in Hotspot to do deadlock detection and print >>> stacktraces. >> >> Ok, I see, thanks. "jstack -F" fails on all combinations, including >> jdk7u12-ea vs. jdk7u12-ea with: >> >> Attaching to process ID 20721, please wait... >> Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: >> Can't attach to the process >> >> I will be glad to follow up on this, if only I could reproduce this >> locally. Is there something else should be enabled to reproduce this? > > It needs to be run as root to be able to attach to the process as a debugger. Gotcha. hotspot-rt -> hotspot-rt fails with the exception you mention. Looking. Thanks! -Aleksey. From aleksey.shipilev at oracle.com Wed Jan 16 01:38:44 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 13:38:44 +0400 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA Message-ID: <50F67524.9030007@oracle.com> Hi, Please consider this little fix for the regression which eluded the testing for @Contended SA changes. It's embarrassing how simple the issue really is: http://cr.openjdk.java.net/~shade/8006403/webrev.00/ Credit goes to Staffan Larsen for first discovering this failure. -Aleksey. From staffan.larsen at oracle.com Wed Jan 16 01:45:33 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Jan 2013 10:45:33 +0100 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F67524.9030007@oracle.com> References: <50F67524.9030007@oracle.com> Message-ID: Thanks for jumping on this. Shouldn't this be looked up the same way the other constants are looked up? Something like: FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); Thanks, /Staffan On 16 jan 2013, at 10:38, Aleksey Shipilev wrote: > Hi, > > Please consider this little fix for the regression which eluded the > testing for @Contended SA changes. It's embarrassing how simple the > issue really is: > http://cr.openjdk.java.net/~shade/8006403/webrev.00/ > > Credit goes to Staffan Larsen for first discovering this failure. > > -Aleksey. From aleksey.shipilev at oracle.com Wed Jan 16 01:49:03 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 13:49:03 +0400 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: References: <50F67524.9030007@oracle.com> Message-ID: <50F6778F.9090004@oracle.com> On 01/16/2013 01:45 PM, Staffan Larsen wrote: > Thanks for jumping on this. That's my sin to write that dumb code in the first place. > Shouldn't this be looked up the same way the other constants are looked up? Something like: > > FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); Yes, that occurred to me as well, see updated webrev: http://cr.openjdk.java.net/~shade/8006403/webrev.02/ Tested that jstack now works fine. -Aleksey. From staffan.larsen at oracle.com Wed Jan 16 02:03:49 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Jan 2013 11:03:49 +0100 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F6778F.9090004@oracle.com> References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> Message-ID: Looks good to me (not a Reviewer). Thanks, /Staffan On 16 jan 2013, at 10:49, Aleksey Shipilev wrote: > On 01/16/2013 01:45 PM, Staffan Larsen wrote: >> Thanks for jumping on this. > > That's my sin to write that dumb code in the first place. > >> Shouldn't this be looked up the same way the other constants are looked up? Something like: >> >> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); > > Yes, that occurred to me as well, see updated webrev: > http://cr.openjdk.java.net/~shade/8006403/webrev.02/ > > Tested that jstack now works fine. > > -Aleksey. From christian.tornqvist at oracle.com Wed Jan 16 04:34:51 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Wed, 16 Jan 2013 04:34:51 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Message-ID: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Hi everyone, ? This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ ? Thanks, Christian From bengt.rutisson at oracle.com Wed Jan 16 04:59:00 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 16 Jan 2013 13:59:00 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <361618c6-904b-4dde-bd65-fd255f0d8112@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: <50F6A414.2050504@oracle.com> Looks good. Bengt On 1/16/13 1:34 PM, Christian T?rnqvist wrote: > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian From david.holmes at oracle.com Wed Jan 16 05:07:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jan 2013 23:07:08 +1000 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> Message-ID: <50F6A5FC.1070603@oracle.com> Me too. (Reviewer) :) Thanks, David On 16/01/2013 8:03 PM, Staffan Larsen wrote: > Looks good to me (not a Reviewer). > > Thanks, > /Staffan > > On 16 jan 2013, at 10:49, Aleksey Shipilev wrote: > >> On 01/16/2013 01:45 PM, Staffan Larsen wrote: >>> Thanks for jumping on this. >> >> That's my sin to write that dumb code in the first place. >> >>> Shouldn't this be looked up the same way the other constants are looked up? Something like: >>> >>> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); >> >> Yes, that occurred to me as well, see updated webrev: >> http://cr.openjdk.java.net/~shade/8006403/webrev.02/ >> >> Tested that jstack now works fine. >> >> -Aleksey. > From mikael.gerdin at oracle.com Wed Jan 16 05:40:31 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Jan 2013 14:40:31 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <361618c6-904b-4dde-bd65-fd255f0d8112@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: <50F6ADCF.8080901@oracle.com> Christian, On 2013-01-16 13:34, Christian T?rnqvist wrote: > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ Looks good to me. /Mikael > > > > Thanks, > > Christian > -- Mikael Gerdin Java SE VM SQE Stockholm From vitalyd at gmail.com Wed Jan 16 05:50:28 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 16 Jan 2013 08:50:28 -0500 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <361618c6-904b-4dde-bd65-fd255f0d8112@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: Hi Christian, Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. There are some other things that can be done, but not sure it's worth the effort for a testing utility. Let me know though if you'd like to cover everything. Thanks Sent from my phone On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" < christian.tornqvist at oracle.com> wrote: > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write > multi-process tests in jtreg, webrev can be found at > http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian > From coleen.phillimore at oracle.com Wed Jan 16 05:53:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Jan 2013 08:53:11 -0500 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <361618c6-904b-4dde-bd65-fd255f0d8112@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: <50F6B0C7.4040405@oracle.com> Christian, Can you write up (somewhere!) what these are for and how these are going to be used? I don't understand just from this code. Does jtreg know enough to build these classfiles? Do we have to write shell scripts to refer to these? Thanks, Coleen On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian From vitalyd at gmail.com Wed Jan 16 05:58:03 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 16 Jan 2013 08:58:03 -0500 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F6B0C7.4040405@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> Message-ID: Hi Coleen, Bengt has a CR using this: http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/ Thanks Sent from my phone On Jan 16, 2013 8:54 AM, "Coleen Phillimore" wrote: > > Christian, > Can you write up (somewhere!) what these are for and how these are going > to be used? I don't understand just from this code. Does jtreg know > enough to build these classfiles? Do we have to write shell scripts to > refer to these? > Thanks, > Coleen > > On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: > >> Hi everyone, >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~**brutisso/8006413/webrev.00/ >> >> >> Thanks, >> >> Christian >> > From bengt.rutisson at oracle.com Wed Jan 16 06:33:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 16 Jan 2013 15:33:06 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> Message-ID: <50F6BA22.5030305@oracle.com> Vitaly, Thanks for connecting the dots here! Coleen, I thin Vitaly is right. You can use my webrev as an example of how Chrisitan's test library is supposed to be used. Bengt On 1/16/13 2:58 PM, Vitaly Davidovich wrote: > Hi Coleen, > > Bengt has a CR using this: > http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/ > > Thanks > > Sent from my phone > On Jan 16, 2013 8:54 AM, "Coleen Phillimore" > wrote: > >> Christian, >> Can you write up (somewhere!) what these are for and how these are going >> to be used? I don't understand just from this code. Does jtreg know >> enough to build these classfiles? Do we have to write shell scripts to >> refer to these? >> Thanks, >> Coleen >> >> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >> >>> Hi everyone, >>> >>> >>> This RFE adds a few utility classes to make it a bit easier to write >>> multi-process tests in jtreg, webrev can be found at >>> http://cr.openjdk.java.net/~**brutisso/8006413/webrev.00/ >>> >>> >>> Thanks, >>> >>> Christian >>> From christian.tornqvist at oracle.com Wed Jan 16 06:42:03 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Wed, 16 Jan 2013 06:42:03 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> Hi Vitaly, ? Setting them as daemon sounds like a good idea :) ? I'd like your feedback on the other things as well, the quality of test code is important. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: den 16 januari 2013 14:50 To: Christian T?rnqvist Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Hi Christian, Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. There are some other things that can be done, but not sure it's worth the effort for a testing utility.? Let me know though if you'd like to cover everything. Thanks Sent from my phone On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: Hi everyone, ? This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ ? Thanks, Christian From nils.loodin at oracle.com Wed Jan 16 06:56:24 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 16 Jan 2013 15:56:24 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <361618c6-904b-4dde-bd65-fd255f0d8112@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: <50F6BF98.8010309@oracle.com> Looks nice! Apart from Vitalys feedback, a few nits: JDKToolFinder.java, OutputAnalyzer : javadoc? Had some in ProcessTools.java, it looked nice :) OutputAnalyzer: single character variable names ProcessTools.java:84 Javadoc should probably describe intent, not the current hack-implementation ;) (that could perhaps be mentioned in a comment in the method StreamPumper.java:34,34 Variable name sin and sout isn't pretty perhaps, since they're mentioned in the javadoc for the run()-method. Regards, Nils Loodin On 01/16/2013 01:34 PM, Christian T?rnqvist wrote: > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian From vitalyd at gmail.com Wed Jan 16 07:29:32 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 16 Jan 2013 10:29:32 -0500 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> Message-ID: Some of this is style so feel free to ignore: I'd mark all these classes final for now. I'd also hide the default ctor for the util classes that only have static methods. JDKToolFinder - Check that the jdk.test sysprop is not empty as well. - Remove the throws clause from the method - don't think it adds any value. - RuntimeException seems more idiomatic instead of Exception - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here). Perhaps even return a File or Path instance instead of string. OutputAnalyzer - any reason fields are default visible? Make them private and final. - should probably check that output is not null in the constructors - it's possible to chain the constructors here - same comment about throws clauses on methods + RuntimeException as above ProcessTools - getOutput swallows IOException and returns "". Not sure this is best - I think the test should fail as you can't trust the results at this point. - StreamPumper extends Thread so I don't think you need the wrapper threads here. Cleaner is to make StreamPumper implement Runnable though and use threads here. - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate. I'd let the interrupt bubble up. - there's no non-reflective way to get the pid? - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. StreamPumper - check ctor args for null reference. The fields can be final as well. That's all for now :). Thanks Sent from my phone On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" < christian.tornqvist at oracle.com> wrote: > Hi Vitaly,**** > > ** ** > > Setting them as daemon sounds like a good idea :)**** > > ** ** > > I?d like your feedback on the other things as well, the quality of test > code is important.**** > > ** ** > > Thanks,**** > > Christian**** > > ** ** > > *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com] > *Sent:* den 16 januari 2013 14:50 > *To:* Christian T?rnqvist > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: RFR (S): 8006413: Add utility classes for writing better > multiprocess tests in jtreg**** > > ** ** > > Hi Christian,**** > > Not sure how polished you want/need this code to be since it's just > utility, but one thing that jumped out was the stream pumper threads for > reading stdout/err should be daemonized just to play it safe.**** > > There are some other things that can be done, but not sure it's worth the > effort for a testing utility. Let me know though if you'd like to cover > everything.**** > > Thanks**** > > Sent from my phone**** > > On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" < > christian.tornqvist at oracle.com> wrote:**** > > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write > multi-process tests in jtreg, webrev can be found at > http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian**** > From staffan.larsen at oracle.com Wed Jan 16 08:05:30 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Jan 2013 17:05:30 +0100 Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167) In-Reply-To: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com> References: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com> Message-ID: <7D0A160B-08F2-4F9F-99A1-95D54555E47E@oracle.com> All, The Event-Based JVM Tracing work is now ready for integration into jdk8. The changes compared to jdk7 are mostly caused by the removal of the permanent generation. Webrev: http://cr.openjdk.java.net/~sla/jep167/jdk8-webrev.01/ This diff is against the jdk8/jdk8 forest at the jdk8-b72 tag. Thanks, /Staffan On 3 dec 2012, at 12:32, Staffan Larsen wrote: > All, > > This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change. > > The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/ > The JEP is here: http://openjdk.java.net/jeps/167 > > The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events. > > To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty. > > These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag. > > Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser > > Comments, questions and suggestions are welcome! > > Thanks, > /Staffan From coleen.phillimore at oracle.com Wed Jan 16 08:08:32 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Jan 2013 11:08:32 -0500 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F6BA22.5030305@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F6BA22.5030305@oracle.com> Message-ID: <50F6D080.3060402@oracle.com> So having the line 30 * @library /testlibrary magically includes this? I won't have this webrev in my mailbox an hour from now, so as Karen requested, can we have some guidance how to write jtreg tests for hotspot specific tests? There is a long writeup in http://openjdk.java.net/jtreg/faq.html but it doesn't include anything like this. Thanks, Coleen On 1/16/2013 9:33 AM, Bengt Rutisson wrote: > > Vitaly, > > Thanks for connecting the dots here! > > Coleen, > > I thin Vitaly is right. You can use my webrev as an example of how > Chrisitan's test library is supposed to be used. > > Bengt > > On 1/16/13 2:58 PM, Vitaly Davidovich wrote: >> Hi Coleen, >> >> Bengt has a CR using this: >> http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/ >> >> Thanks >> >> Sent from my phone >> On Jan 16, 2013 8:54 AM, "Coleen Phillimore" >> >> wrote: >> >>> Christian, >>> Can you write up (somewhere!) what these are for and how these are >>> going >>> to be used? I don't understand just from this code. Does jtreg know >>> enough to build these classfiles? Do we have to write shell >>> scripts to >>> refer to these? >>> Thanks, >>> Coleen >>> >>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>> >>>> Hi everyone, >>>> >>>> >>>> This RFE adds a few utility classes to make it a bit easier to write >>>> multi-process tests in jtreg, webrev can be found at >>>> http://cr.openjdk.java.net/~**brutisso/8006413/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> > From vladimir.kozlov at oracle.com Wed Jan 16 09:09:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jan 2013 09:09:04 -0800 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F6778F.9090004@oracle.com> References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> Message-ID: <50F6DEB0.9010604@oracle.com> Good. Vladimir On 1/16/13 1:49 AM, Aleksey Shipilev wrote: > On 01/16/2013 01:45 PM, Staffan Larsen wrote: >> Thanks for jumping on this. > > That's my sin to write that dumb code in the first place. > >> Shouldn't this be looked up the same way the other constants are looked up? Something like: >> >> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); > > Yes, that occurred to me as well, see updated webrev: > http://cr.openjdk.java.net/~shade/8006403/webrev.02/ > > Tested that jstack now works fine. > > -Aleksey. > From jesper.wilhelmsson at oracle.com Wed Jan 16 09:26:05 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 16 Jan 2013 18:26:05 +0100 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F6DEB0.9010604@oracle.com> References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> <50F6DEB0.9010604@oracle.com> Message-ID: <50F6E2AD.5070205@oracle.com> OK, since these changes are in hotspot I'll sponsor this change as well. I'm getting it ready for JPRT now (will do some local testing first) and will push later today. /Jesper On 2013-01-16 18:09, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 1/16/13 1:49 AM, Aleksey Shipilev wrote: >> On 01/16/2013 01:45 PM, Staffan Larsen wrote: >>> Thanks for jumping on this. >> >> That's my sin to write that dumb code in the first place. >> >>> Shouldn't this be looked up the same way the other constants are looked up? >>> Something like: >>> >>> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); >> >> Yes, that occurred to me as well, see updated webrev: >> http://cr.openjdk.java.net/~shade/8006403/webrev.02/ >> >> Tested that jstack now works fine. >> >> -Aleksey. >> From aleksey.shipilev at oracle.com Wed Jan 16 09:33:50 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 21:33:50 +0400 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F6E2AD.5070205@oracle.com> References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> <50F6DEB0.9010604@oracle.com> <50F6E2AD.5070205@oracle.com> Message-ID: I think Staffan had already submitted the JPRT job to integrate. -Aleksey. On 16.01.2013, at 21:26, Jesper Wilhelmsson wrote: > OK, since these changes are in hotspot I'll sponsor this change as well. > I'm getting it ready for JPRT now (will do some local testing first) and will push later today. > /Jesper > > On 2013-01-16 18:09, Vladimir Kozlov wrote: >> Good. >> >> Vladimir >> >> On 1/16/13 1:49 AM, Aleksey Shipilev wrote: >>> On 01/16/2013 01:45 PM, Staffan Larsen wrote: >>>> Thanks for jumping on this. >>> >>> That's my sin to write that dumb code in the first place. >>> >>>> Shouldn't this be looked up the same way the other constants are looked up? >>>> Something like: >>>> >>>> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); >>> >>> Yes, that occurred to me as well, see updated webrev: >>> http://cr.openjdk.java.net/~shade/8006403/webrev.02/ >>> >>> Tested that jstack now works fine. >>> >>> -Aleksey. >>> From jesper.wilhelmsson at oracle.com Wed Jan 16 09:42:38 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 16 Jan 2013 18:42:38 +0100 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> <50F6DEB0.9010604@oracle.com> <50F6E2AD.5070205@oracle.com> Message-ID: <50F6E68E.4070603@oracle.com> OK, then I won't :-) /Jesper On 2013-01-16 18:33, Aleksey Shipilev wrote: > I think Staffan had already submitted the JPRT job to integrate. > > -Aleksey. > > On 16.01.2013, at 21:26, Jesper Wilhelmsson wrote: > >> OK, since these changes are in hotspot I'll sponsor this change as well. >> I'm getting it ready for JPRT now (will do some local testing first) and will push later today. >> /Jesper >> >> On 2013-01-16 18:09, Vladimir Kozlov wrote: >>> Good. >>> >>> Vladimir >>> >>> On 1/16/13 1:49 AM, Aleksey Shipilev wrote: >>>> On 01/16/2013 01:45 PM, Staffan Larsen wrote: >>>>> Thanks for jumping on this. >>>> >>>> That's my sin to write that dumb code in the first place. >>>> >>>>> Shouldn't this be looked up the same way the other constants are looked up? >>>>> Something like: >>>>> >>>>> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); >>>> >>>> Yes, that occurred to me as well, see updated webrev: >>>> http://cr.openjdk.java.net/~shade/8006403/webrev.02/ >>>> >>>> Tested that jstack now works fine. >>>> >>>> -Aleksey. >>>> From staffan.larsen at oracle.com Wed Jan 16 12:38:00 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Jan 2013 21:38:00 +0100 Subject: RFR (XS) CR 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F6E68E.4070603@oracle.com> References: <50F67524.9030007@oracle.com> <50F6778F.9090004@oracle.com> <50F6DEB0.9010604@oracle.com> <50F6E2AD.5070205@oracle.com> <50F6E68E.4070603@oracle.com> Message-ID: <1CC5311D-8DD4-4F0A-AA09-A4438F004292@oracle.com> Yes, the job is in the queue. /Staffan On 16 jan 2013, at 18:42, Jesper Wilhelmsson wrote: > OK, then I won't :-) > /Jesper > > On 2013-01-16 18:33, Aleksey Shipilev wrote: >> I think Staffan had already submitted the JPRT job to integrate. >> >> -Aleksey. >> >> On 16.01.2013, at 21:26, Jesper Wilhelmsson wrote: >> >>> OK, since these changes are in hotspot I'll sponsor this change as well. >>> I'm getting it ready for JPRT now (will do some local testing first) and will push later today. >>> /Jesper >>> >>> On 2013-01-16 18:09, Vladimir Kozlov wrote: >>>> Good. >>>> >>>> Vladimir >>>> >>>> On 1/16/13 1:49 AM, Aleksey Shipilev wrote: >>>>> On 01/16/2013 01:45 PM, Staffan Larsen wrote: >>>>>> Thanks for jumping on this. >>>>> >>>>> That's my sin to write that dumb code in the first place. >>>>> >>>>>> Shouldn't this be looked up the same way the other constants are looked up? >>>>>> Something like: >>>>>> >>>>>> FIELDINFO_TAG_MASK = db.lookupIntConstant("FIELDINFO_TAG_MASK").shortValue(); >>>>> >>>>> Yes, that occurred to me as well, see updated webrev: >>>>> http://cr.openjdk.java.net/~shade/8006403/webrev.02/ >>>>> >>>>> Tested that jstack now works fine. >>>>> >>>>> -Aleksey. >>>>> From serguei.spitsyn at oracle.com Wed Jan 16 13:46:26 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 16 Jan 2013 13:46:26 -0800 Subject: Review Request (S) 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Message-ID: <50F71FB2.4020702@oracle.com> Please, review the fix for: https://jbs.oracle.com/bugs/browse/JDK-8005128 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8005128-JVMTI-JSR292.0/ Summary: When constant pool is copied by the merge_constant_pools() the invokedynamic operands must be copied in a right order. The pool_holder needs to be set before copying the operands. Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Will check if any jtreg tests are useful. Thanks, Serguei From stuart.marks at oracle.com Wed Jan 16 13:54:09 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 16 Jan 2013 13:54:09 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <361618c6-904b-4dde-bd65-fd255f0d8112@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> Message-ID: <50F72181.7080307@oracle.com> Hi everybody, I work on the JDK core libraries. It turns out that there is a similar library used for testing RMI. Take a look at jdk/test/java/rmi/testlibrary. It's been around for quite some time already, but I've been doing some maintenance on it recently. (Also, it still needs more work.) Since the RMI library is in the jdk repo and these test utilities are in hotspot, it seems like sharing of code might be difficult. But we might want to compare notes. Here are some observations and comments (though not an actual code review). * The use of a pair of threads (StreamPumper) to collect output from the subprocess is very similar to what RMI does. See the StreamPipe class in RMI's test library, which are used by the JavaVM utility class. One thing I did do recently was to make sure that the subprocess is waited for and the threads are joined. This hadn't been done before, leading to race conditions where some subprocess output was dropped. * Since these threads are specifically joined, I'm not sure of the utility of making them daemon threads. * My style in writing test code and test library code is to be quite verbose about everything and to check every possible error condition. Nothing is worse than seeing a test fail and not having enough information in the log to find out why. Actually, I can think of something worse: having a test pass erroneously because some error condition wasn't checked. (Yes, this has happened.) * Another style point is that I think it's OK for test library code just to throw exceptions out to the caller. My test code usually has 'throws IOException' or even 'throws Exception' on most of the methods, including main, so having test library code throw checked exceptions is reasonable. Jtreg will catch exceptions thrown from main and log them. Usually you want tests to fail quickly at the point of error. So, I concur with Vitaly's concern about ProcessTools handling of IOException and about letting interrupts propagate. * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe threads to catch exceptions and report them back to their "parent" JavaVM. This is probably a rare occurrence but it does ensure that any errors that occur here won't go unnoticed. See JDK-8005827 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) * Regarding jtreg and test library code, it's pretty simple to use. In each test that uses the library code, one adds the @library tag to declare the library. It's probably a good idea to add an @build tag to build each library class that's used in the test. Things usually work in the absence of @build tags, because of implicit compilation, but it's kind of fragile. Anyway, I just wanted to share some notes and ideas. s'marks On 1/16/13 4:34 AM, Christian T?rnqvist wrote: > Hi everyone, > > ? > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > ? > > Thanks, > > Christian > From vitalyd at gmail.com Wed Jan 16 15:08:31 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 16 Jan 2013 18:08:31 -0500 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F72181.7080307@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> Message-ID: Stuart, You want them daemon here because prior to joining on them, it calls waitFor() on the process. If it gets interrupted, the join calls are skipped. Now, it may end up that those threads will exit anyway due to their run loop exiting if process dies and streams return an error or read -1. However, instead of relying on that "global context/knowledge" it seems easier/more robust to just daemonize them. My $.02 Thanks Sent from my phone On Jan 16, 2013 4:52 PM, "Stuart Marks" wrote: > Hi everybody, > > I work on the JDK core libraries. It turns out that there is a similar > library used for testing RMI. Take a look at jdk/test/java/rmi/testlibrary. > It's been around for quite some time already, but I've been doing some > maintenance on it recently. (Also, it still needs more work.) > > Since the RMI library is in the jdk repo and these test utilities are in > hotspot, it seems like sharing of code might be difficult. But we might > want to compare notes. Here are some observations and comments (though not > an actual code review). > > * The use of a pair of threads (StreamPumper) to collect output from the > subprocess is very similar to what RMI does. See the StreamPipe class in > RMI's test library, which are used by the JavaVM utility class. One thing I > did do recently was to make sure that the subprocess is waited for and the > threads are joined. This hadn't been done before, leading to race > conditions where some subprocess output was dropped. > > * Since these threads are specifically joined, I'm not sure of the utility > of making them daemon threads. > > * My style in writing test code and test library code is to be quite > verbose about everything and to check every possible error condition. > Nothing is worse than seeing a test fail and not having enough information > in the log to find out why. Actually, I can think of something worse: > having a test pass erroneously because some error condition wasn't checked. > (Yes, this has happened.) > > * Another style point is that I think it's OK for test library code just > to throw exceptions out to the caller. My test code usually has 'throws > IOException' or even 'throws Exception' on most of the methods, including > main, so having test library code throw checked exceptions is reasonable. > Jtreg will catch exceptions thrown from main and log them. Usually you want > tests to fail quickly at the point of error. So, I concur with Vitaly's > concern about ProcessTools handling of IOException and about letting > interrupts propagate. > > * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe > threads to catch exceptions and report them back to their "parent" JavaVM. > This is probably a rare occurrence but it does ensure that any errors that > occur here won't go unnoticed. See JDK-8005827 ( http://bugs.sun.com/** > bugdatabase/view_bug.do?bug_**id=8005827) > > * Regarding jtreg and test library code, it's pretty simple to use. In > each test that uses the library code, one adds the @library tag to declare > the library. It's probably a good idea to add an @build tag to build each > library class that's used in the test. Things usually work in the absence > of @build tags, because of implicit compilation, but it's kind of fragile. > > Anyway, I just wanted to share some notes and ideas. > > s'marks > > > On 1/16/13 4:34 AM, Christian T?rnqvist wrote: > >> Hi everyone, >> >> ? >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~**brutisso/8006413/webrev.00/ >> >> ? >> >> Thanks, >> >> Christian >> >> From coleen.phillimore at oracle.com Wed Jan 16 18:27:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Jan 2013 21:27:39 -0500 Subject: Review Request (S) 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <50F7619B.4080909@oracle.com> Serguei, This code looks good. Thank you for fixing this. Co;eem On 1/16/2013 4:46 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://jbs.oracle.com/bugs/browse/JDK-8005128 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8005128-JVMTI-JSR292.0/ > > > Summary: > When constant pool is copied by the merge_constant_pools() > the invokedynamic operands must be copied in a right order. > The pool_holder needs to be set before copying the operands. > > Testing: > nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > Will check if any jtreg tests are useful. > > Thanks, > Serguei From karen.kinnear at oracle.com Wed Jan 16 19:18:36 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 17 Jan 2013 03:18:36 +0000 Subject: hg: hsx/hotspot-main/hotspot: 14 new changesets Message-ID: <20130117031904.AEFBB4732F@hg.openjdk.java.net> Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/97ee8abd6ab2 Merge Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/90a92d5bca17 Merge Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp From dmitry.samersoff at oracle.com Thu Jan 17 05:13:40 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 17:13:40 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F6B0C7.4040405@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> Message-ID: <50F7F904.3050004@oracle.com> Christian, 1. I'm second to Coleen. Is it possible to add more comments explaining how to use this tools. 2. Is it possible to create your own exception rather than use Exceptioin class directly. 3. Who is responsible to kill started process? -Dmitry On 2013-01-16 17:53, Coleen Phillimore wrote: > > Christian, > Can you write up (somewhere!) what these are for and how these are going > to be used? I don't understand just from this code. Does jtreg know > enough to build these classfiles? Do we have to write shell scripts to > refer to these? > Thanks, > Coleen > > On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >> Hi everyone, >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> >> Thanks, >> >> Christian -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Thu Jan 17 05:20:27 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 17:20:27 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F72181.7080307@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> Message-ID: <50F7FA9B.40101@oracle.com> Stuart, > I work on the JDK core libraries. It turns out that there is a similar > library used for testing RMI. I guess if we take close look to exising tests we would find couple more copies of the same ideas. Is it possible to have a library like this one included into jtreg and available for everybody ? -Dmitry On 2013-01-17 01:54, Stuart Marks wrote: > Hi everybody, > > I work on the JDK core libraries. It turns out that there is a similar > library used for testing RMI. Take a look at > jdk/test/java/rmi/testlibrary. It's been around for quite some time > already, but I've been doing some maintenance on it recently. (Also, it > still needs more work.) > > Since the RMI library is in the jdk repo and these test utilities are in > hotspot, it seems like sharing of code might be difficult. But we might > want to compare notes. Here are some observations and comments (though > not an actual code review). > > * The use of a pair of threads (StreamPumper) to collect output from the > subprocess is very similar to what RMI does. See the StreamPipe class in > RMI's test library, which are used by the JavaVM utility class. One > thing I did do recently was to make sure that the subprocess is waited > for and the threads are joined. This hadn't been done before, leading to > race conditions where some subprocess output was dropped. > > * Since these threads are specifically joined, I'm not sure of the > utility of making them daemon threads. > > * My style in writing test code and test library code is to be quite > verbose about everything and to check every possible error condition. > Nothing is worse than seeing a test fail and not having enough > information in the log to find out why. Actually, I can think of > something worse: having a test pass erroneously because some error > condition wasn't checked. (Yes, this has happened.) > > * Another style point is that I think it's OK for test library code just > to throw exceptions out to the caller. My test code usually has 'throws > IOException' or even 'throws Exception' on most of the methods, > including main, so having test library code throw checked exceptions is > reasonable. Jtreg will catch exceptions thrown from main and log them. > Usually you want tests to fail quickly at the point of error. So, I > concur with Vitaly's concern about ProcessTools handling of IOException > and about letting interrupts propagate. > > * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe > threads to catch exceptions and report them back to their "parent" > JavaVM. This is probably a rare occurrence but it does ensure that any > errors that occur here won't go unnoticed. See JDK-8005827 ( > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) > > * Regarding jtreg and test library code, it's pretty simple to use. In > each test that uses the library code, one adds the @library tag to > declare the library. It's probably a good idea to add an @build tag to > build each library class that's used in the test. Things usually work in > the absence of @build tags, because of implicit compilation, but it's > kind of fragile. > > Anyway, I just wanted to share some notes and ideas. > > s'marks > > > On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >> Hi everyone, >> >> ? >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> ? >> >> Thanks, >> >> Christian >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From christian.tornqvist at oracle.com Thu Jan 17 06:01:37 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 06:01:37 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F7FA9B.40101@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> Message-ID: > Is it possible to have a library like this one included into jtreg and available for everybody ? The problem with this is that suddenly the tests have a dependency on jtreg. One (of many) nice things with the jtreg tests is that they can be run as a normal java program without the need to involve jtreg, making debugging and troubleshooting them a lot easier. Best regards, Christian -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Stuart, > I work on the JDK core libraries. It turns out that there is a similar > library used for testing RMI. I guess if we take close look to exising tests we would find couple more copies of the same ideas. Is it possible to have a library like this one included into jtreg and available for everybody ? -Dmitry On 2013-01-17 01:54, Stuart Marks wrote: > Hi everybody, > > I work on the JDK core libraries. It turns out that there is a similar > library used for testing RMI. Take a look at > jdk/test/java/rmi/testlibrary. It's been around for quite some time > already, but I've been doing some maintenance on it recently. (Also, > it still needs more work.) > > Since the RMI library is in the jdk repo and these test utilities are > in hotspot, it seems like sharing of code might be difficult. But we > might want to compare notes. Here are some observations and comments > (though not an actual code review). > > * The use of a pair of threads (StreamPumper) to collect output from > the subprocess is very similar to what RMI does. See the StreamPipe > class in RMI's test library, which are used by the JavaVM utility > class. One thing I did do recently was to make sure that the > subprocess is waited for and the threads are joined. This hadn't been > done before, leading to race conditions where some subprocess output was dropped. > > * Since these threads are specifically joined, I'm not sure of the > utility of making them daemon threads. > > * My style in writing test code and test library code is to be quite > verbose about everything and to check every possible error condition. > Nothing is worse than seeing a test fail and not having enough > information in the log to find out why. Actually, I can think of > something worse: having a test pass erroneously because some error > condition wasn't checked. (Yes, this has happened.) > > * Another style point is that I think it's OK for test library code > just to throw exceptions out to the caller. My test code usually has > 'throws IOException' or even 'throws Exception' on most of the > methods, including main, so having test library code throw checked > exceptions is reasonable. Jtreg will catch exceptions thrown from main and log them. > Usually you want tests to fail quickly at the point of error. So, I > concur with Vitaly's concern about ProcessTools handling of > IOException and about letting interrupts propagate. > > * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe > threads to catch exceptions and report them back to their "parent" > JavaVM. This is probably a rare occurrence but it does ensure that any > errors that occur here won't go unnoticed. See JDK-8005827 ( > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) > > * Regarding jtreg and test library code, it's pretty simple to use. In > each test that uses the library code, one adds the @library tag to > declare the library. It's probably a good idea to add an @build tag to > build each library class that's used in the test. Things usually work > in the absence of @build tags, because of implicit compilation, but > it's kind of fragile. > > Anyway, I just wanted to share some notes and ideas. > > s'marks > > > On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >> Hi everyone, >> >> ? >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> ? >> >> Thanks, >> >> Christian >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Thu Jan 17 06:05:53 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 18:05:53 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> Message-ID: <50F80541.9080006@oracle.com> Christian, On my opinion something like import com.oracle.jtreg.tools.* is less painful than maintain several independent implementations of the same ideas. -Dmitry On 2013-01-17 18:01, Christian T?rnqvist wrote: >> Is it possible to have a library like this one included into jtreg >> and available for everybody ? > > The problem with this is that suddenly the tests have a dependency on > jtreg. One (of many) nice things with the jtreg tests is that they > can be run as a normal java program without the need to involve > jtreg, making debugging and troubleshooting them a lot easier. > > Best regards, Christian > > -----Original Message----- From: Dmitry Samersoff Sent: den 17 > januari 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; > hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): > 8006413: Add utility classes for writing better multiprocess tests in > jtreg > > Stuart, > >> I work on the JDK core libraries. It turns out that there is a >> similar library used for testing RMI. > > I guess if we take close look to exising tests we would find couple > more copies of the same ideas. > > Is it possible to have a library like this one included into jtreg > and available for everybody ? > > -Dmitry > > > On 2013-01-17 01:54, Stuart Marks wrote: >> Hi everybody, >> >> I work on the JDK core libraries. It turns out that there is a >> similar library used for testing RMI. Take a look at >> jdk/test/java/rmi/testlibrary. It's been around for quite some time >> already, but I've been doing some maintenance on it recently. >> (Also, it still needs more work.) >> >> Since the RMI library is in the jdk repo and these test utilities >> are in hotspot, it seems like sharing of code might be difficult. >> But we might want to compare notes. Here are some observations and >> comments (though not an actual code review). >> >> * The use of a pair of threads (StreamPumper) to collect output >> from the subprocess is very similar to what RMI does. See the >> StreamPipe class in RMI's test library, which are used by the >> JavaVM utility class. One thing I did do recently was to make sure >> that the subprocess is waited for and the threads are joined. This >> hadn't been done before, leading to race conditions where some >> subprocess output was dropped. >> >> * Since these threads are specifically joined, I'm not sure of the >> utility of making them daemon threads. >> >> * My style in writing test code and test library code is to be >> quite verbose about everything and to check every possible error >> condition. Nothing is worse than seeing a test fail and not having >> enough information in the log to find out why. Actually, I can >> think of something worse: having a test pass erroneously because >> some error condition wasn't checked. (Yes, this has happened.) >> >> * Another style point is that I think it's OK for test library code >> just to throw exceptions out to the caller. My test code usually >> has 'throws IOException' or even 'throws Exception' on most of the >> methods, including main, so having test library code throw checked >> exceptions is reasonable. Jtreg will catch exceptions thrown from >> main and log them. Usually you want tests to fail quickly at the >> point of error. So, I concur with Vitaly's concern about >> ProcessTools handling of IOException and about letting interrupts >> propagate. >> >> * Actually I have a suggestion from Mandy Chung for RMI's >> StreamPipe threads to catch exceptions and report them back to >> their "parent" JavaVM. This is probably a rare occurrence but it >> does ensure that any errors that occur here won't go unnoticed. See >> JDK-8005827 ( >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >> >> * Regarding jtreg and test library code, it's pretty simple to use. >> In each test that uses the library code, one adds the @library tag >> to declare the library. It's probably a good idea to add an @build >> tag to build each library class that's used in the test. Things >> usually work in the absence of @build tags, because of implicit >> compilation, but it's kind of fragile. >> >> Anyway, I just wanted to share some notes and ideas. >> >> s'marks >> >> >> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>> Hi everyone, >>> >>> ? >>> >>> This RFE adds a few utility classes to make it a bit easier to >>> write multi-process tests in jtreg, webrev can be found at >>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>> >>> ? >>> >>> Thanks, >>> >>> Christian >>> > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, > Russia * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From christian.tornqvist at oracle.com Thu Jan 17 06:10:19 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 06:10:19 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F80541.9080006@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> Message-ID: Well, jtreg is not in the hotspot repo (and shouldn't be) and suddenly you end up having an external dependency. I'd like to keep the tests free from dependence on jtreg (along with other external resources). Thanks, Christian -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari 2013 15:06 To: Christian T?rnqvist Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Christian, On my opinion something like import com.oracle.jtreg.tools.* is less painful than maintain several independent implementations of the same ideas. -Dmitry On 2013-01-17 18:01, Christian T?rnqvist wrote: >> Is it possible to have a library like this one included into jtreg >> and available for everybody ? > > The problem with this is that suddenly the tests have a dependency on > jtreg. One (of many) nice things with the jtreg tests is that they can > be run as a normal java program without the need to involve jtreg, > making debugging and troubleshooting them a lot easier. > > Best regards, Christian > > -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari > 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; > hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): > 8006413: Add utility classes for writing better multiprocess tests in > jtreg > > Stuart, > >> I work on the JDK core libraries. It turns out that there is a >> similar library used for testing RMI. > > I guess if we take close look to exising tests we would find couple > more copies of the same ideas. > > Is it possible to have a library like this one included into jtreg and > available for everybody ? > > -Dmitry > > > On 2013-01-17 01:54, Stuart Marks wrote: >> Hi everybody, >> >> I work on the JDK core libraries. It turns out that there is a >> similar library used for testing RMI. Take a look at >> jdk/test/java/rmi/testlibrary. It's been around for quite some time >> already, but I've been doing some maintenance on it recently. >> (Also, it still needs more work.) >> >> Since the RMI library is in the jdk repo and these test utilities are >> in hotspot, it seems like sharing of code might be difficult. >> But we might want to compare notes. Here are some observations and >> comments (though not an actual code review). >> >> * The use of a pair of threads (StreamPumper) to collect output from >> the subprocess is very similar to what RMI does. See the StreamPipe >> class in RMI's test library, which are used by the JavaVM utility >> class. One thing I did do recently was to make sure that the >> subprocess is waited for and the threads are joined. This hadn't been >> done before, leading to race conditions where some subprocess output >> was dropped. >> >> * Since these threads are specifically joined, I'm not sure of the >> utility of making them daemon threads. >> >> * My style in writing test code and test library code is to be quite >> verbose about everything and to check every possible error condition. >> Nothing is worse than seeing a test fail and not having enough >> information in the log to find out why. Actually, I can think of >> something worse: having a test pass erroneously because some error >> condition wasn't checked. (Yes, this has happened.) >> >> * Another style point is that I think it's OK for test library code >> just to throw exceptions out to the caller. My test code usually has >> 'throws IOException' or even 'throws Exception' on most of the >> methods, including main, so having test library code throw checked >> exceptions is reasonable. Jtreg will catch exceptions thrown from >> main and log them. Usually you want tests to fail quickly at the >> point of error. So, I concur with Vitaly's concern about ProcessTools >> handling of IOException and about letting interrupts propagate. >> >> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe >> threads to catch exceptions and report them back to their "parent" >> JavaVM. This is probably a rare occurrence but it does ensure that >> any errors that occur here won't go unnoticed. See >> JDK-8005827 ( >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >> >> * Regarding jtreg and test library code, it's pretty simple to use. >> In each test that uses the library code, one adds the @library tag to >> declare the library. It's probably a good idea to add an @build tag >> to build each library class that's used in the test. Things usually >> work in the absence of @build tags, because of implicit compilation, >> but it's kind of fragile. >> >> Anyway, I just wanted to share some notes and ideas. >> >> s'marks >> >> >> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>> Hi everyone, >>> >>> ? >>> >>> This RFE adds a few utility classes to make it a bit easier to write >>> multi-process tests in jtreg, webrev can be found at >>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>> >>> ? >>> >>> Thanks, >>> >>> Christian >>> > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, > Russia * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From christian.tornqvist at oracle.com Thu Jan 17 06:10:41 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 06:10:41 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F7F904.3050004@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> Message-ID: <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> Hi Dmitry, > 1. I'm second to Coleen. Is it possible to add more comments explaining how to use this tools. My intention is to write a detailed guide to writing jtreg tests, including the use of these (and future) utility classes. > 2. Is it possible to create your own exception rather than use Exceptioin class directly. I've changed it to use RuntimeException based on feedback from other people > 3. Who is responsible to kill started process? This is really a task for the jtreg framework. Honestly it doesn't really do this very well right now, since the process handling in Java is not good enough to deal with this. I think this is a something we should look into addressing in jtreg rather than having the tests worry about it. Best regards, Christian -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari 2013 14:14 To: Coleen Phillimore Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Christian, 1. I'm second to Coleen. Is it possible to add more comments explaining how to use this tools. 2. Is it possible to create your own exception rather than use Exceptioin class directly. 3. Who is responsible to kill started process? -Dmitry On 2013-01-16 17:53, Coleen Phillimore wrote: > > Christian, > Can you write up (somewhere!) what these are for and how these are going > to be used? I don't understand just from this code. Does jtreg know > enough to build these classfiles? Do we have to write shell scripts to > refer to these? > Thanks, > Coleen > > On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >> Hi everyone, >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> >> Thanks, >> >> Christian -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From christian.tornqvist at oracle.com Thu Jan 17 06:19:09 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 06:19:09 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> Message-ID: <829105df-e94f-4512-a97e-9608b9817bcb@default> Hi Vitaly, First of all, thanks for all your feedback :) >- not entirely sure what getPlatformSpecificVMArgs is really meant for.? Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra >braces) This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. >- there's no non-reflective way to get the pid? Not that I've found :( ? I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: den 16 januari 2013 16:30 To: Christian T?rnqvist Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Some of this is style so feel free to ignore: I'd mark all these classes final for now.? I'd also hide the default ctor for the util classes that only have static methods. JDKToolFinder - Check that the jdk.test sysprop is not empty as well. - Remove the throws clause from the method - don't think it adds any value. - RuntimeException seems more idiomatic instead of Exception - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here).? Perhaps even return a File or Path instance instead of string. OutputAnalyzer - any reason fields are default visible? Make them private and final. - should probably check that output is not null in the constructors - it's possible to chain the constructors here - same comment about throws clauses on methods + RuntimeException as above ProcessTools - getOutput swallows IOException and returns "".? Not sure this is best - I think the test should fail as you can't trust the results at this point. - StreamPumper extends Thread so I don't think you need the wrapper threads here.? Cleaner is to make StreamPumper implement Runnable though and use threads here. - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate.? I'd let the interrupt bubble up. - there's no non-reflective way to get the pid? - not entirely sure what getPlatformSpecificVMArgs is really meant for.? Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. StreamPumper - check ctor args for null reference.? The fields can be final as well. That's all for now :). Thanks Sent from my phone On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: Hi Vitaly, ? Setting them as daemon sounds like a good idea :) ? I'd like your feedback on the other things as well, the quality of test code is important. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" \nvitalyd at gmail.com] Sent: den 16 januari 2013 14:50 To: Christian T?rnqvist Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" \nhotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Hi Christian, Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. There are some other things that can be done, but not sure it's worth the effort for a testing utility.? Let me know though if you'd like to cover everything. Thanks Sent from my phone On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: Hi everyone, ? This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ ? Thanks, Christian From nils.loodin at oracle.com Thu Jan 17 06:34:11 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 17 Jan 2013 15:34:11 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> Message-ID: <50F80BE3.5000306@oracle.com> On 01/17/2013 03:10 PM, Christian T?rnqvist wrote: > Well, jtreg is not in the hotspot repo (and shouldn't be) and suddenly you end up having an external dependency. I'd like to keep the tests free from dependence on jtreg (along with other external resources). > > Thanks, > Christian > > -----Original Message----- > From: Dmitry Samersoff > Sent: den 17 januari 2013 15:06 > To: Christian T?rnqvist > Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons > Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Christian, > > On my opinion something like > > import com.oracle.jtreg.tools.* > > is less painful than maintain several independent implementations of the same ideas. > > -Dmitry > I fully agree with Christian here. Dmitry, you have to see the pain from the people who are debugging the tests here, not the one implementing. The thresholds for rerunning / modifying / debugging tests will be very very much increased when introducing such dependencies! Regards, Nils Loodin From dmitry.samersoff at oracle.com Thu Jan 17 06:59:07 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 18:59:07 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> Message-ID: <50F811BB.3060803@oracle.com> On 2013-01-17 18:10, Christian T?rnqvist wrote: > Hi Dmitry, > >> 1. I'm second to Coleen. Is it possible to add more comments >> explaining how to use this tools. > > My intention is to write a detailed guide to writing jtreg tests, > including the use of these (and future) utility classes. Good. >> 2. Is it possible to create your own exception rather than use >> Exceptioin class directly. > > I've changed it to use RuntimeException based on feedback from other > people Please create your own exception class. I would like to be able to distinguish between exceptions that comes from different parts of tests. >> 3. Who is responsible to kill started process? > > This is really a task for the jtreg framework. Honestly it doesn't > really do this very well right now, since the process handling in > Java is not good enough to deal with this. I think this is a > something we should look into addressing in jtreg rather than having > the tests worry about it. What is benefits of this library over usual shell script? -Dmitry > > Best regards, Christian > > -----Original Message----- From: Dmitry Samersoff Sent: den 17 > januari 2013 14:14 To: Coleen Phillimore Cc: > hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add > utility classes for writing better multiprocess tests in jtreg > > Christian, > > 1. I'm second to Coleen. Is it possible to add more comments > explaining how to use this tools. > > > 2. Is it possible to create your own exception rather than use > Exceptioin class directly. > > > 3. Who is responsible to kill started process? > > -Dmitry > > > On 2013-01-16 17:53, Coleen Phillimore wrote: >> >> Christian, Can you write up (somewhere!) what these are for and how >> these are going to be used? I don't understand just from this >> code. Does jtreg know enough to build these classfiles? Do we >> have to write shell scripts to refer to these? Thanks, Coleen >> >> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>> Hi everyone, >>> >>> >>> This RFE adds a few utility classes to make it a bit easier to >>> write multi-process tests in jtreg, webrev can be found at >>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>> >>> >>> Thanks, >>> >>> Christian > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, > Russia * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From christian.tornqvist at oracle.com Thu Jan 17 07:15:23 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 07:15:23 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F811BB.3060803@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> Message-ID: > What is benefits of this library over usual shell script? It works on all platforms, also the code is a lot cleaner and easier to maintain. Thanks, Christian -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari 2013 15:59 To: Christian T?rnqvist Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg On 2013-01-17 18:10, Christian T?rnqvist wrote: > Hi Dmitry, > >> 1. I'm second to Coleen. Is it possible to add more comments >> explaining how to use this tools. > > My intention is to write a detailed guide to writing jtreg tests, > including the use of these (and future) utility classes. Good. >> 2. Is it possible to create your own exception rather than use >> Exceptioin class directly. > > I've changed it to use RuntimeException based on feedback from other > people Please create your own exception class. I would like to be able to distinguish between exceptions that comes from different parts of tests. >> 3. Who is responsible to kill started process? > > This is really a task for the jtreg framework. Honestly it doesn't > really do this very well right now, since the process handling in Java > is not good enough to deal with this. I think this is a something we > should look into addressing in jtreg rather than having the tests > worry about it. What is benefits of this library over usual shell script? -Dmitry > > Best regards, Christian > > -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari > 2013 14:14 To: Coleen Phillimore Cc: > hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add > utility classes for writing better multiprocess tests in jtreg > > Christian, > > 1. I'm second to Coleen. Is it possible to add more comments > explaining how to use this tools. > > > 2. Is it possible to create your own exception rather than use > Exceptioin class directly. > > > 3. Who is responsible to kill started process? > > -Dmitry > > > On 2013-01-16 17:53, Coleen Phillimore wrote: >> >> Christian, Can you write up (somewhere!) what these are for and how >> these are going to be used? I don't understand just from this >> code. Does jtreg know enough to build these classfiles? Do we >> have to write shell scripts to refer to these? Thanks, Coleen >> >> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>> Hi everyone, >>> >>> >>> This RFE adds a few utility classes to make it a bit easier to write >>> multi-process tests in jtreg, webrev can be found at >>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>> >>> >>> Thanks, >>> >>> Christian > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, > Russia * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Thu Jan 17 07:15:37 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 19:15:37 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F80BE3.5000306@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> <50F80BE3.5000306@oracle.com> Message-ID: <50F81599.6030306@oracle.com> Nils, Sorry, I don't see any pain of placing all libraries necessary to support tests to a separate place and use it from there. And on my opinion, jtreg workspace is a good place to add something like testtools.jar As the worst case, it's acceptable to sync with Stuart and keep two copy of the same library - but not two different ones doing the same, with different class names, exceptions and bugs. Otherwise, if my fix contains bot hotspot and jdk parts, my tests would have to use (and I would have to learn) two different libraries. -Dmitry On 2013-01-17 18:34, Nils Loodin wrote: > On 01/17/2013 03:10 PM, Christian T?rnqvist wrote: >> Well, jtreg is not in the hotspot repo (and shouldn't be) and suddenly >> you end up having an external dependency. I'd like to keep the tests >> free from dependence on jtreg (along with other external resources). >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 17 januari 2013 15:06 >> To: Christian T?rnqvist >> Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Christian, >> >> On my opinion something like >> >> import com.oracle.jtreg.tools.* >> >> is less painful than maintain several independent implementations of >> the same ideas. >> >> -Dmitry >> > > I fully agree with Christian here. Dmitry, you have to see the pain from > the people who are debugging the tests here, not the one implementing. > The thresholds for rerunning / modifying / debugging tests will be very > very much increased when introducing such dependencies! > > Regards, > Nils Loodin -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From joe.darcy at oracle.com Thu Jan 17 08:34:44 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Jan 2013 08:34:44 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> Message-ID: <50F82824.8070909@oracle.com> On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >> What is benefits of this library over usual shell script? > It works on all platforms, also the code is a lot cleaner and easier to maintain. Shell tests are awful. We should strive to not only stop adding more shell tests, I think we should work to convert existing shell tests into Java programs. I've been looking a bit at the set of tests with transient failures are shell tests are overrepresented on that list. Writing cross platform shell code is tricky and the shells on some platforms have a history of being at least one of slow and unreliable. Additionally, the test themselves often have bugs. For example, Alan Bateman just recently pushed a changest to have the tests properly respect environment variables passed in by jtreg [1]. -Joe [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 > > Thanks, > Christian > > -----Original Message----- > From: Dmitry Samersoff > Sent: den 17 januari 2013 15:59 > To: Christian T?rnqvist > Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > On 2013-01-17 18:10, Christian T?rnqvist wrote: >> Hi Dmitry, >> >>> 1. I'm second to Coleen. Is it possible to add more comments >>> explaining how to use this tools. >> My intention is to write a detailed guide to writing jtreg tests, >> including the use of these (and future) utility classes. > Good. > >>> 2. Is it possible to create your own exception rather than use >>> Exceptioin class directly. >> I've changed it to use RuntimeException based on feedback from other >> people > Please create your own exception class. I would like to be able to distinguish between exceptions that comes from different parts of tests. > >>> 3. Who is responsible to kill started process? >> This is really a task for the jtreg framework. Honestly it doesn't >> really do this very well right now, since the process handling in Java >> is not good enough to deal with this. I think this is a something we >> should look into addressing in jtreg rather than having the tests >> worry about it. > What is benefits of this library over usual shell script? > > -Dmitry > > >> Best regards, Christian >> >> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >> 2013 14:14 To: Coleen Phillimore Cc: >> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >> utility classes for writing better multiprocess tests in jtreg >> >> Christian, >> >> 1. I'm second to Coleen. Is it possible to add more comments >> explaining how to use this tools. >> >> >> 2. Is it possible to create your own exception rather than use >> Exceptioin class directly. >> >> >> 3. Who is responsible to kill started process? >> >> -Dmitry >> >> >> On 2013-01-16 17:53, Coleen Phillimore wrote: >>> Christian, Can you write up (somewhere!) what these are for and how >>> these are going to be used? I don't understand just from this >>> code. Does jtreg know enough to build these classfiles? Do we >>> have to write shell scripts to refer to these? Thanks, Coleen >>> >>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>> Hi everyone, >>>> >>>> >>>> This RFE adds a few utility classes to make it a bit easier to write >>>> multi-process tests in jtreg, webrev can be found at >>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Christian >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * Give Rabbit time, and he'll always get the answer >> > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer From christian.tornqvist at oracle.com Thu Jan 17 08:44:24 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 08:44:24 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <829105df-e94f-4512-a97e-9608b9817bcb@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> Message-ID: Updated webrev can be found at http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots of small changes based on all the great feedback I got :) Thanks, Christian -----Original Message----- From: Christian T?rnqvist Sent: den 17 januari 2013 15:19 To: Vitaly Davidovich Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Hi Vitaly, First of all, thanks for all your feedback :) >- not entirely sure what getPlatformSpecificVMArgs is really meant for.? Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra >braces) This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. >- there's no non-reflective way to get the pid? Not that I've found :( ? I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: den 16 januari 2013 16:30 To: Christian T?rnqvist Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Some of this is style so feel free to ignore: I'd mark all these classes final for now.? I'd also hide the default ctor for the util classes that only have static methods. JDKToolFinder - Check that the jdk.test sysprop is not empty as well. - Remove the throws clause from the method - don't think it adds any value. - RuntimeException seems more idiomatic instead of Exception - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here).? Perhaps even return a File or Path instance instead of string. OutputAnalyzer - any reason fields are default visible? Make them private and final. - should probably check that output is not null in the constructors - it's possible to chain the constructors here - same comment about throws clauses on methods + RuntimeException as above ProcessTools - getOutput swallows IOException and returns "".? Not sure this is best - I think the test should fail as you can't trust the results at this point. - StreamPumper extends Thread so I don't think you need the wrapper threads here.? Cleaner is to make StreamPumper implement Runnable though and use threads here. - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate.? I'd let the interrupt bubble up. - there's no non-reflective way to get the pid? - not entirely sure what getPlatformSpecificVMArgs is really meant for.? Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. StreamPumper - check ctor args for null reference.? The fields can be final as well. That's all for now :). Thanks Sent from my phone On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: Hi Vitaly, ? Setting them as daemon sounds like a good idea :) ? I'd like your feedback on the other things as well, the quality of test code is important. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" \nvitalyd at gmail.com] Sent: den 16 januari 2013 14:50 To: Christian T?rnqvist Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" \nhotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Hi Christian, Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. There are some other things that can be done, but not sure it's worth the effort for a testing utility.? Let me know though if you'd like to cover everything. Thanks Sent from my phone On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: Hi everyone, ? This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ ? Thanks, Christian From dmitry.samersoff at oracle.com Thu Jan 17 09:02:38 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 21:02:38 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F82824.8070909@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> Message-ID: <50F82EAE.3020100@oracle.com> Joe, The devil is not in shell scripts. The devil is in the fact that harness (jtreg) doesn't have a process management and doesn't support client server tests. Shell initially designed to manage processes but java not, so replacing shell scripts to java based process builder that exec java from within java that exec another java doesn't make things better and just leads to the new layer of errors. I guess we should invest some time and efforts to jtreg and finaly being able to write something like (approximately) @run/server/timeout=300 someClass @run/client someClass and then use jtreg.getServerPid(), jtreg.shutdownServer() etc. Then I vote with two hands for getting rid of all shell based tests. But today I see no benefits from replacing java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -version | grep "warning: Using incremental CMS is deprecated" to a 16 lines of Java code ( http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/test/gc/startup-warnings/TestCMSIncrementalMode.java.html ) -Dmitry On 2013-01-17 20:34, Joe Darcy wrote: > On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >>> What is benefits of this library over usual shell script? >> It works on all platforms, also the code is a lot cleaner and easier >> to maintain. > > Shell tests are awful. We should strive to not only stop adding more > shell tests, I think we should work to convert existing shell tests into > Java programs. > > I've been looking a bit at the set of tests with transient failures are > shell tests are overrepresented on that list. Writing cross platform > shell code is tricky and the shells on some platforms have a history of > being at least one of slow and unreliable. Additionally, the test > themselves often have bugs. For example, Alan Bateman just recently > pushed a changest to have the tests properly respect environment > variables passed in by jtreg [1]. > > -Joe > > [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and > other tools > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 > >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 17 januari 2013 15:59 >> To: Christian T?rnqvist >> Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> On 2013-01-17 18:10, Christian T?rnqvist wrote: >>> Hi Dmitry, >>> >>>> 1. I'm second to Coleen. Is it possible to add more comments >>>> explaining how to use this tools. >>> My intention is to write a detailed guide to writing jtreg tests, >>> including the use of these (and future) utility classes. >> Good. >> >>>> 2. Is it possible to create your own exception rather than use >>>> Exceptioin class directly. >>> I've changed it to use RuntimeException based on feedback from other >>> people >> Please create your own exception class. I would like to be able to >> distinguish between exceptions that comes from different parts of tests. >> >>>> 3. Who is responsible to kill started process? >>> This is really a task for the jtreg framework. Honestly it doesn't >>> really do this very well right now, since the process handling in Java >>> is not good enough to deal with this. I think this is a something we >>> should look into addressing in jtreg rather than having the tests >>> worry about it. >> What is benefits of this library over usual shell script? >> >> -Dmitry >> >> >>> Best regards, Christian >>> >>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>> 2013 14:14 To: Coleen Phillimore Cc: >>> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >>> utility classes for writing better multiprocess tests in jtreg >>> >>> Christian, >>> >>> 1. I'm second to Coleen. Is it possible to add more comments >>> explaining how to use this tools. >>> >>> >>> 2. Is it possible to create your own exception rather than use >>> Exceptioin class directly. >>> >>> >>> 3. Who is responsible to kill started process? >>> >>> -Dmitry >>> >>> >>> On 2013-01-16 17:53, Coleen Phillimore wrote: >>>> Christian, Can you write up (somewhere!) what these are for and how >>>> these are going to be used? I don't understand just from this >>>> code. Does jtreg know enough to build these classfiles? Do we >>>> have to write shell scripts to refer to these? Thanks, Coleen >>>> >>>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> >>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>> multi-process tests in jtreg, webrev can be found at >>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * Give Rabbit time, and he'll always get the answer >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Thu Jan 17 09:07:49 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 21:07:49 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> Message-ID: <50F82FE5.3050801@oracle.com> Christian, I hardly suggest to add something like: TestToolException extends RuntimeException { } otherwise a developer would not be able to distinguish between a test action and a tool library failure if the test action results bare RuntimeException. -Dmitry On 2013-01-17 20:44, Christian T?rnqvist wrote: > Updated webrev can be found at http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots of small changes based on all the great feedback I got :) > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 15:19 > To: Vitaly Davidovich > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Hi Vitaly, > > First of all, thanks for all your feedback :) > >> - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra >braces) > > This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. > >> - there's no non-reflective way to get the pid? > > Not that I've found :( > > > > I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: den 16 januari 2013 16:30 > To: Christian T?rnqvist > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > > > Some of this is style so feel free to ignore: > > I'd mark all these classes final for now. I'd also hide the default ctor for the util classes that only have static methods. > > JDKToolFinder > - Check that the jdk.test sysprop is not empty as well. > > - Remove the throws clause from the method - don't think it adds any value. > > - RuntimeException seems more idiomatic instead of Exception > > - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here). Perhaps even return a File or Path instance instead of string. > > OutputAnalyzer > - any reason fields are default visible? Make them private and final. > > - should probably check that output is not null in the constructors > > - it's possible to chain the constructors here > > - same comment about throws clauses on methods + RuntimeException as above > > ProcessTools > - getOutput swallows IOException and returns "". Not sure this is best - I think the test should fail as you can't trust the results at this point. > > - StreamPumper extends Thread so I don't think you need the wrapper threads here. Cleaner is to make StreamPumper implement Runnable though and use threads here. > > - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate. I'd let the interrupt bubble up. > > - there's no non-reflective way to get the pid? > > - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) > > -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. > > StreamPumper > - check ctor args for null reference. The fields can be final as well. > > That's all for now :). > > Thanks > Sent from my phone > > On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: > > Hi Vitaly, > > > > Setting them as daemon sounds like a good idea :) > > > > I'd like your feedback on the other things as well, the quality of test code is important. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" \nvitalyd at gmail.com] > Sent: den 16 januari 2013 14:50 > To: Christian T?rnqvist > Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" \nhotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > > > Hi Christian, > > Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. > > There are some other things that can be done, but not sure it's worth the effort for a testing utility. Let me know though if you'd like to cover everything. > > Thanks > > Sent from my phone > > On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: > > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From kelly.ohair at oracle.com Thu Jan 17 09:14:06 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 17 Jan 2013 09:14:06 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F82EAE.3020100@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> <50F82EAE.3020100@oracle.com> Message-ID: Yes the devil is in shell scripts. Yes it's a pain to program client/server tests with pure Java, but with pure Java you can share that logic much safer than shell scripts. It's even more painful to get client/server tests to work reliably in shell scripts, on all platforms. Shell tests have been so problematic for so long that we need to start forcing the issue, 'no more shell tests' should now be the rule. Developers need to figure out how to share Java client/server logic between tests and stop adding more to this shell test nightmare. -kto On Jan 17, 2013, at 9:02 AM, Dmitry Samersoff wrote: > Joe, > > The devil is not in shell scripts. The devil is in the fact that > harness (jtreg) doesn't have a process management and doesn't support > client server tests. > > Shell initially designed to manage processes but java not, so replacing > shell scripts to java based process builder that exec java from within > java that exec another java doesn't make things better and just leads to > the new layer of errors. > > I guess we should invest some time and efforts to jtreg and finaly being > able to write something like (approximately) > > @run/server/timeout=300 someClass > @run/client someClass > > and then use > jtreg.getServerPid(), > jtreg.shutdownServer() > > etc. > > Then I vote with two hands for getting rid of all shell based tests. > > But today I see no benefits from replacing > > java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -version | > grep "warning: Using incremental CMS is deprecated" > > to a 16 lines of Java code ( > http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/test/gc/startup-warnings/TestCMSIncrementalMode.java.html > ) > > > -Dmitry > > > > > On 2013-01-17 20:34, Joe Darcy wrote: >> On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >>>> What is benefits of this library over usual shell script? >>> It works on all platforms, also the code is a lot cleaner and easier >>> to maintain. >> >> Shell tests are awful. We should strive to not only stop adding more >> shell tests, I think we should work to convert existing shell tests into >> Java programs. >> >> I've been looking a bit at the set of tests with transient failures are >> shell tests are overrepresented on that list. Writing cross platform >> shell code is tricky and the shells on some platforms have a history of >> being at least one of slow and unreliable. Additionally, the test >> themselves often have bugs. For example, Alan Bateman just recently >> pushed a changest to have the tests properly respect environment >> variables passed in by jtreg [1]. >> >> -Joe >> >> [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and >> other tools >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 >> >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: den 17 januari 2013 15:59 >>> To: Christian T?rnqvist >>> Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> On 2013-01-17 18:10, Christian T?rnqvist wrote: >>>> Hi Dmitry, >>>> >>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>> explaining how to use this tools. >>>> My intention is to write a detailed guide to writing jtreg tests, >>>> including the use of these (and future) utility classes. >>> Good. >>> >>>>> 2. Is it possible to create your own exception rather than use >>>>> Exceptioin class directly. >>>> I've changed it to use RuntimeException based on feedback from other >>>> people >>> Please create your own exception class. I would like to be able to >>> distinguish between exceptions that comes from different parts of tests. >>> >>>>> 3. Who is responsible to kill started process? >>>> This is really a task for the jtreg framework. Honestly it doesn't >>>> really do this very well right now, since the process handling in Java >>>> is not good enough to deal with this. I think this is a something we >>>> should look into addressing in jtreg rather than having the tests >>>> worry about it. >>> What is benefits of this library over usual shell script? >>> >>> -Dmitry >>> >>> >>>> Best regards, Christian >>>> >>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>> 2013 14:14 To: Coleen Phillimore Cc: >>>> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >>>> utility classes for writing better multiprocess tests in jtreg >>>> >>>> Christian, >>>> >>>> 1. I'm second to Coleen. Is it possible to add more comments >>>> explaining how to use this tools. >>>> >>>> >>>> 2. Is it possible to create your own exception rather than use >>>> Exceptioin class directly. >>>> >>>> >>>> 3. Who is responsible to kill started process? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2013-01-16 17:53, Coleen Phillimore wrote: >>>>> Christian, Can you write up (somewhere!) what these are for and how >>>>> these are going to be used? I don't understand just from this >>>>> code. Does jtreg know enough to build these classfiles? Do we >>>>> have to write shell scripts to refer to these? Thanks, Coleen >>>>> >>>>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>>>> Hi everyone, >>>>>> >>>>>> >>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>> multi-process tests in jtreg, webrev can be found at >>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Christian >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * Give Rabbit time, and he'll always get the answer >>>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * Give Rabbit time, and he'll always get the answer >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer From kelly.ohair at oracle.com Thu Jan 17 09:17:49 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 17 Jan 2013 09:17:49 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> Message-ID: <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> The C compiler, bash, libraries, unix utilities, aren't in the repo. We will have and always have external dependencies. I agree we need to limit them, but a testing harness (ideally one) is a very valid external dependency to have. Hotspot needs to get lined up with the standard jdk testing, jtreg is already used in jdk, JPRT, QE teams, and many developers are very familiar with it. -kto On Jan 17, 2013, at 6:10 AM, Christian T?rnqvist wrote: > Well, jtreg is not in the hotspot repo (and shouldn't be) and suddenly you end up having an external dependency. I'd like to keep the tests free from dependence on jtreg (along with other external resources). > > Thanks, > Christian > > -----Original Message----- > From: Dmitry Samersoff > Sent: den 17 januari 2013 15:06 > To: Christian T?rnqvist > Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons > Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Christian, > > On my opinion something like > > import com.oracle.jtreg.tools.* > > is less painful than maintain several independent implementations of the same ideas. > > -Dmitry > > > On 2013-01-17 18:01, Christian T?rnqvist wrote: >>> Is it possible to have a library like this one included into jtreg >>> and available for everybody ? >> >> The problem with this is that suddenly the tests have a dependency on >> jtreg. One (of many) nice things with the jtreg tests is that they can >> be run as a normal java program without the need to involve jtreg, >> making debugging and troubleshooting them a lot easier. >> >> Best regards, Christian >> >> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >> 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; >> hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): >> 8006413: Add utility classes for writing better multiprocess tests in >> jtreg >> >> Stuart, >> >>> I work on the JDK core libraries. It turns out that there is a >>> similar library used for testing RMI. >> >> I guess if we take close look to exising tests we would find couple >> more copies of the same ideas. >> >> Is it possible to have a library like this one included into jtreg and >> available for everybody ? >> >> -Dmitry >> >> >> On 2013-01-17 01:54, Stuart Marks wrote: >>> Hi everybody, >>> >>> I work on the JDK core libraries. It turns out that there is a >>> similar library used for testing RMI. Take a look at >>> jdk/test/java/rmi/testlibrary. It's been around for quite some time >>> already, but I've been doing some maintenance on it recently. >>> (Also, it still needs more work.) >>> >>> Since the RMI library is in the jdk repo and these test utilities are >>> in hotspot, it seems like sharing of code might be difficult. >>> But we might want to compare notes. Here are some observations and >>> comments (though not an actual code review). >>> >>> * The use of a pair of threads (StreamPumper) to collect output from >>> the subprocess is very similar to what RMI does. See the StreamPipe >>> class in RMI's test library, which are used by the JavaVM utility >>> class. One thing I did do recently was to make sure that the >>> subprocess is waited for and the threads are joined. This hadn't been >>> done before, leading to race conditions where some subprocess output >>> was dropped. >>> >>> * Since these threads are specifically joined, I'm not sure of the >>> utility of making them daemon threads. >>> >>> * My style in writing test code and test library code is to be quite >>> verbose about everything and to check every possible error condition. >>> Nothing is worse than seeing a test fail and not having enough >>> information in the log to find out why. Actually, I can think of >>> something worse: having a test pass erroneously because some error >>> condition wasn't checked. (Yes, this has happened.) >>> >>> * Another style point is that I think it's OK for test library code >>> just to throw exceptions out to the caller. My test code usually has >>> 'throws IOException' or even 'throws Exception' on most of the >>> methods, including main, so having test library code throw checked >>> exceptions is reasonable. Jtreg will catch exceptions thrown from >>> main and log them. Usually you want tests to fail quickly at the >>> point of error. So, I concur with Vitaly's concern about ProcessTools >>> handling of IOException and about letting interrupts propagate. >>> >>> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe >>> threads to catch exceptions and report them back to their "parent" >>> JavaVM. This is probably a rare occurrence but it does ensure that >>> any errors that occur here won't go unnoticed. See >>> JDK-8005827 ( >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >>> >>> * Regarding jtreg and test library code, it's pretty simple to use. >>> In each test that uses the library code, one adds the @library tag to >>> declare the library. It's probably a good idea to add an @build tag >>> to build each library class that's used in the test. Things usually >>> work in the absence of @build tags, because of implicit compilation, >>> but it's kind of fragile. >>> >>> Anyway, I just wanted to share some notes and ideas. >>> >>> s'marks >>> >>> >>> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>>> Hi everyone, >>>> >>>> ? >>>> >>>> This RFE adds a few utility classes to make it a bit easier to write >>>> multi-process tests in jtreg, webrev can be found at >>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>> >>>> ? >>>> >>>> Thanks, >>>> >>>> Christian >>>> >> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * Give Rabbit time, and he'll always get the answer >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer From doug.simon at oracle.com Thu Jan 17 09:20:07 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Jan 2013 18:20:07 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F82EAE.3020100@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> <50F82EAE.3020100@oracle.com> Message-ID: What about using something with (most of) the facilities and succinctness of bash while being more of a programming language? For instance, python. Sent from my iPhone On Jan 17, 2013, at 6:02 PM, Dmitry Samersoff wrote: > Joe, > > The devil is not in shell scripts. The devil is in the fact that > harness (jtreg) doesn't have a process management and doesn't support > client server tests. > > Shell initially designed to manage processes but java not, so replacing > shell scripts to java based process builder that exec java from within > java that exec another java doesn't make things better and just leads to > the new layer of errors. > > I guess we should invest some time and efforts to jtreg and finaly being > able to write something like (approximately) > > @run/server/timeout=300 someClass > @run/client someClass > > and then use > jtreg.getServerPid(), > jtreg.shutdownServer() > > etc. > > Then I vote with two hands for getting rid of all shell based tests. > > But today I see no benefits from replacing > > java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -version | > grep "warning: Using incremental CMS is deprecated" > > to a 16 lines of Java code ( > http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/test/gc/startup-warnings/TestCMSIncrementalMode.java.html > ) > > > -Dmitry > > > > > On 2013-01-17 20:34, Joe Darcy wrote: >> On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >>>> What is benefits of this library over usual shell script? >>> It works on all platforms, also the code is a lot cleaner and easier >>> to maintain. >> >> Shell tests are awful. We should strive to not only stop adding more >> shell tests, I think we should work to convert existing shell tests into >> Java programs. >> >> I've been looking a bit at the set of tests with transient failures are >> shell tests are overrepresented on that list. Writing cross platform >> shell code is tricky and the shells on some platforms have a history of >> being at least one of slow and unreliable. Additionally, the test >> themselves often have bugs. For example, Alan Bateman just recently >> pushed a changest to have the tests properly respect environment >> variables passed in by jtreg [1]. >> >> -Joe >> >> [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and >> other tools >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 >> >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: den 17 januari 2013 15:59 >>> To: Christian T?rnqvist >>> Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> On 2013-01-17 18:10, Christian T?rnqvist wrote: >>>> Hi Dmitry, >>>> >>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>> explaining how to use this tools. >>>> My intention is to write a detailed guide to writing jtreg tests, >>>> including the use of these (and future) utility classes. >>> Good. >>> >>>>> 2. Is it possible to create your own exception rather than use >>>>> Exceptioin class directly. >>>> I've changed it to use RuntimeException based on feedback from other >>>> people >>> Please create your own exception class. I would like to be able to >>> distinguish between exceptions that comes from different parts of tests. >>> >>>>> 3. Who is responsible to kill started process? >>>> This is really a task for the jtreg framework. Honestly it doesn't >>>> really do this very well right now, since the process handling in Java >>>> is not good enough to deal with this. I think this is a something we >>>> should look into addressing in jtreg rather than having the tests >>>> worry about it. >>> What is benefits of this library over usual shell script? >>> >>> -Dmitry >>> >>> >>>> Best regards, Christian >>>> >>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>> 2013 14:14 To: Coleen Phillimore Cc: >>>> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >>>> utility classes for writing better multiprocess tests in jtreg >>>> >>>> Christian, >>>> >>>> 1. I'm second to Coleen. Is it possible to add more comments >>>> explaining how to use this tools. >>>> >>>> >>>> 2. Is it possible to create your own exception rather than use >>>> Exceptioin class directly. >>>> >>>> >>>> 3. Who is responsible to kill started process? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2013-01-16 17:53, Coleen Phillimore wrote: >>>>> Christian, Can you write up (somewhere!) what these are for and how >>>>> these are going to be used? I don't understand just from this >>>>> code. Does jtreg know enough to build these classfiles? Do we >>>>> have to write shell scripts to refer to these? Thanks, Coleen >>>>> >>>>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>>>> Hi everyone, >>>>>> >>>>>> >>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>> multi-process tests in jtreg, webrev can be found at >>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Christian >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * Give Rabbit time, and he'll always get the answer >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * Give Rabbit time, and he'll always get the answer > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Thu Jan 17 09:28:50 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 21:28:50 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F8338B.6020104@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> <50F8338B.6020104@oracle.com> Message-ID: <50F834D2.60304@oracle.com> Jonathan, Just to clarify, I propose: 1. Add TestTools directory to JTREG workspace. 2. Build TestTools.jar together with jtreg 3. Maintain and distribute TestTools.jar together with jtreg under jtreg policies. 4. Add /TestTools.jar to default classpath for all tests. 5. Use import com.oracle.jtreg.tools.* when necessary. -Dmitry On 2013-01-17 21:23, Jonathan Gibbons wrote: > I think there's a confusion here between an external dependency on the > test harness (which has generally been deemed acceptable) and a > potentially new external dependencies on test libraries in other > repositories in the forest, which would see less acceptable to me. > > There /are/ times when cut-n-paste is the correct solution. :-) > > -- Jon > > On 01/17/2013 09:17 AM, Kelly O'Hair wrote: >> The C compiler, bash, libraries, unix utilities, aren't in the repo. >> We will have and always have >> external dependencies. I agree we need to limit them, but a testing >> harness (ideally one) is a very >> valid external dependency to have. >> >> Hotspot needs to get lined up with the standard jdk testing, jtreg is >> already used in jdk, JPRT, >> QE teams, and many developers are very familiar with it. >> >> -kto >> >> On Jan 17, 2013, at 6:10 AM, Christian T?rnqvist wrote: >> >>> Well, jtreg is not in the hotspot repo (and shouldn't be) and >>> suddenly you end up having an external dependency. I'd like to keep >>> the tests free from dependence on jtreg (along with other external >>> resources). >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: den 17 januari 2013 15:06 >>> To: Christian T?rnqvist >>> Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons >>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> Christian, >>> >>> On my opinion something like >>> >>> import com.oracle.jtreg.tools.* >>> >>> is less painful than maintain several independent implementations of >>> the same ideas. >>> >>> -Dmitry >>> >>> >>> On 2013-01-17 18:01, Christian T?rnqvist wrote: >>>>> Is it possible to have a library like this one included into jtreg >>>>> and available for everybody ? >>>> The problem with this is that suddenly the tests have a dependency on >>>> jtreg. One (of many) nice things with the jtreg tests is that they can >>>> be run as a normal java program without the need to involve jtreg, >>>> making debugging and troubleshooting them a lot easier. >>>> >>>> Best regards, Christian >>>> >>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>> 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; >>>> hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): >>>> 8006413: Add utility classes for writing better multiprocess tests in >>>> jtreg >>>> >>>> Stuart, >>>> >>>>> I work on the JDK core libraries. It turns out that there is a >>>>> similar library used for testing RMI. >>>> I guess if we take close look to exising tests we would find couple >>>> more copies of the same ideas. >>>> >>>> Is it possible to have a library like this one included into jtreg and >>>> available for everybody ? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2013-01-17 01:54, Stuart Marks wrote: >>>>> Hi everybody, >>>>> >>>>> I work on the JDK core libraries. It turns out that there is a >>>>> similar library used for testing RMI. Take a look at >>>>> jdk/test/java/rmi/testlibrary. It's been around for quite some time >>>>> already, but I've been doing some maintenance on it recently. >>>>> (Also, it still needs more work.) >>>>> >>>>> Since the RMI library is in the jdk repo and these test utilities are >>>>> in hotspot, it seems like sharing of code might be difficult. >>>>> But we might want to compare notes. Here are some observations and >>>>> comments (though not an actual code review). >>>>> >>>>> * The use of a pair of threads (StreamPumper) to collect output from >>>>> the subprocess is very similar to what RMI does. See the StreamPipe >>>>> class in RMI's test library, which are used by the JavaVM utility >>>>> class. One thing I did do recently was to make sure that the >>>>> subprocess is waited for and the threads are joined. This hadn't been >>>>> done before, leading to race conditions where some subprocess output >>>>> was dropped. >>>>> >>>>> * Since these threads are specifically joined, I'm not sure of the >>>>> utility of making them daemon threads. >>>>> >>>>> * My style in writing test code and test library code is to be quite >>>>> verbose about everything and to check every possible error condition. >>>>> Nothing is worse than seeing a test fail and not having enough >>>>> information in the log to find out why. Actually, I can think of >>>>> something worse: having a test pass erroneously because some error >>>>> condition wasn't checked. (Yes, this has happened.) >>>>> >>>>> * Another style point is that I think it's OK for test library code >>>>> just to throw exceptions out to the caller. My test code usually has >>>>> 'throws IOException' or even 'throws Exception' on most of the >>>>> methods, including main, so having test library code throw checked >>>>> exceptions is reasonable. Jtreg will catch exceptions thrown from >>>>> main and log them. Usually you want tests to fail quickly at the >>>>> point of error. So, I concur with Vitaly's concern about ProcessTools >>>>> handling of IOException and about letting interrupts propagate. >>>>> >>>>> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe >>>>> threads to catch exceptions and report them back to their "parent" >>>>> JavaVM. This is probably a rare occurrence but it does ensure that >>>>> any errors that occur here won't go unnoticed. See >>>>> JDK-8005827 ( >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >>>>> >>>>> * Regarding jtreg and test library code, it's pretty simple to use. >>>>> In each test that uses the library code, one adds the @library tag to >>>>> declare the library. It's probably a good idea to add an @build tag >>>>> to build each library class that's used in the test. Things usually >>>>> work in the absence of @build tags, because of implicit compilation, >>>>> but it's kind of fragile. >>>>> >>>>> Anyway, I just wanted to share some notes and ideas. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>>>>> Hi everyone, >>>>>> >>>>>> ? >>>>>> >>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>> multi-process tests in jtreg, webrev can be found at >>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>> >>>>>> ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Christian >>>>>> >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * Give Rabbit time, and he'll always get the answer >>>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Thu Jan 17 09:58:23 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Jan 2013 21:58:23 +0400 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> <50F82EAE.3020100@oracle.com> Message-ID: <50F83BBF.5000807@oracle.com> Kelly, We have couple of platform depended points that makes shell tests not reliable: 1. Getting PID of right process 2. Kill running process 3. Remove remaining locks and locked files/directories (e.g. hsperfdata) etc Java has all these problems as well, so I can't imagine why Java based tests (I speak about multiprocess one only) is more reliable than shell ones. The simplest way to improve reliability of shell based tests is write different scripts for windows and for other platforms. On my opinion most of problem with shell scripts is the result of attempt to use unix style programming under windows. (e.g. tlist works much better than ps from MKS or Cygwin) -Dmitry On 2013-01-17 21:14, Kelly O'Hair wrote: > Yes the devil is in shell scripts. Yes it's a pain to program client/server tests with pure Java, > but with pure Java you can share that logic much safer than shell scripts. > It's even more painful to get client/server tests to work reliably in shell scripts, on all platforms. > > Shell tests have been so problematic for so long that we need to start forcing the issue, > 'no more shell tests' should now be the rule. > Developers need to figure out how to share Java client/server logic between tests and stop adding > more to this shell test nightmare. > > -kto > > On Jan 17, 2013, at 9:02 AM, Dmitry Samersoff wrote: > >> Joe, >> >> The devil is not in shell scripts. The devil is in the fact that >> harness (jtreg) doesn't have a process management and doesn't support >> client server tests. >> >> Shell initially designed to manage processes but java not, so replacing >> shell scripts to java based process builder that exec java from within >> java that exec another java doesn't make things better and just leads to >> the new layer of errors. >> >> I guess we should invest some time and efforts to jtreg and finaly being >> able to write something like (approximately) >> >> @run/server/timeout=300 someClass >> @run/client someClass >> >> and then use >> jtreg.getServerPid(), >> jtreg.shutdownServer() >> >> etc. >> >> Then I vote with two hands for getting rid of all shell based tests. >> >> But today I see no benefits from replacing >> >> java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -version | >> grep "warning: Using incremental CMS is deprecated" >> >> to a 16 lines of Java code ( >> http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/test/gc/startup-warnings/TestCMSIncrementalMode.java.html >> ) >> >> >> -Dmitry >> >> >> >> >> On 2013-01-17 20:34, Joe Darcy wrote: >>> On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >>>>> What is benefits of this library over usual shell script? >>>> It works on all platforms, also the code is a lot cleaner and easier >>>> to maintain. >>> >>> Shell tests are awful. We should strive to not only stop adding more >>> shell tests, I think we should work to convert existing shell tests into >>> Java programs. >>> >>> I've been looking a bit at the set of tests with transient failures are >>> shell tests are overrepresented on that list. Writing cross platform >>> shell code is tricky and the shells on some platforms have a history of >>> being at least one of slow and unreliable. Additionally, the test >>> themselves often have bugs. For example, Alan Bateman just recently >>> pushed a changest to have the tests properly respect environment >>> variables passed in by jtreg [1]. >>> >>> -Joe >>> >>> [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and >>> other tools >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 >>> >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Dmitry Samersoff >>>> Sent: den 17 januari 2013 15:59 >>>> To: Christian T?rnqvist >>>> Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>>> multiprocess tests in jtreg >>>> >>>> On 2013-01-17 18:10, Christian T?rnqvist wrote: >>>>> Hi Dmitry, >>>>> >>>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>>> explaining how to use this tools. >>>>> My intention is to write a detailed guide to writing jtreg tests, >>>>> including the use of these (and future) utility classes. >>>> Good. >>>> >>>>>> 2. Is it possible to create your own exception rather than use >>>>>> Exceptioin class directly. >>>>> I've changed it to use RuntimeException based on feedback from other >>>>> people >>>> Please create your own exception class. I would like to be able to >>>> distinguish between exceptions that comes from different parts of tests. >>>> >>>>>> 3. Who is responsible to kill started process? >>>>> This is really a task for the jtreg framework. Honestly it doesn't >>>>> really do this very well right now, since the process handling in Java >>>>> is not good enough to deal with this. I think this is a something we >>>>> should look into addressing in jtreg rather than having the tests >>>>> worry about it. >>>> What is benefits of this library over usual shell script? >>>> >>>> -Dmitry >>>> >>>> >>>>> Best regards, Christian >>>>> >>>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>>> 2013 14:14 To: Coleen Phillimore Cc: >>>>> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >>>>> utility classes for writing better multiprocess tests in jtreg >>>>> >>>>> Christian, >>>>> >>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>> explaining how to use this tools. >>>>> >>>>> >>>>> 2. Is it possible to create your own exception rather than use >>>>> Exceptioin class directly. >>>>> >>>>> >>>>> 3. Who is responsible to kill started process? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-01-16 17:53, Coleen Phillimore wrote: >>>>>> Christian, Can you write up (somewhere!) what these are for and how >>>>>> these are going to be used? I don't understand just from this >>>>>> code. Does jtreg know enough to build these classfiles? Do we >>>>>> have to write shell scripts to refer to these? Thanks, Coleen >>>>>> >>>>>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> >>>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>>> multi-process tests in jtreg, webrev can be found at >>>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Christian >>>>> >>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>> Russia * Give Rabbit time, and he'll always get the answer >>>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * Give Rabbit time, and he'll always get the answer >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * Give Rabbit time, and he'll always get the answer > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From ioi.lam at oracle.com Thu Jan 17 10:02:32 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 17 Jan 2013 10:02:32 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> Message-ID: <50F83CB8.3040309@oracle.com> How do you ensure that the version of the library included in jtreg is in fact consistent with the version of HotSpot/JDK that you are trying to build/test? I have seen that the UTE harness installed at different locations of /java have different versions and are configured differently. And that's just for 'running' the tests. If we have to include such a dependency for 'building' the tests that would be even worse ... - Ioi On 01/17/2013 09:17 AM, Kelly O'Hair wrote: > The C compiler, bash, libraries, unix utilities, aren't in the repo. We will have and always have > external dependencies. I agree we need to limit them, but a testing harness (ideally one) is a very > valid external dependency to have. > > Hotspot needs to get lined up with the standard jdk testing, jtreg is already used in jdk, JPRT, > QE teams, and many developers are very familiar with it. > > -kto > > On Jan 17, 2013, at 6:10 AM, Christian T?rnqvist wrote: > >> Well, jtreg is not in the hotspot repo (and shouldn't be) and suddenly you end up having an external dependency. I'd like to keep the tests free from dependence on jtreg (along with other external resources). >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 17 januari 2013 15:06 >> To: Christian T?rnqvist >> Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg >> >> Christian, >> >> On my opinion something like >> >> import com.oracle.jtreg.tools.* >> >> is less painful than maintain several independent implementations of the same ideas. >> >> -Dmitry >> >> >> On 2013-01-17 18:01, Christian T?rnqvist wrote: >>>> Is it possible to have a library like this one included into jtreg >>>> and available for everybody ? >>> The problem with this is that suddenly the tests have a dependency on >>> jtreg. One (of many) nice things with the jtreg tests is that they can >>> be run as a normal java program without the need to involve jtreg, >>> making debugging and troubleshooting them a lot easier. >>> >>> Best regards, Christian >>> >>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>> 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; >>> hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): >>> 8006413: Add utility classes for writing better multiprocess tests in >>> jtreg >>> >>> Stuart, >>> >>>> I work on the JDK core libraries. It turns out that there is a >>>> similar library used for testing RMI. >>> I guess if we take close look to exising tests we would find couple >>> more copies of the same ideas. >>> >>> Is it possible to have a library like this one included into jtreg and >>> available for everybody ? >>> >>> -Dmitry >>> >>> >>> On 2013-01-17 01:54, Stuart Marks wrote: >>>> Hi everybody, >>>> >>>> I work on the JDK core libraries. It turns out that there is a >>>> similar library used for testing RMI. Take a look at >>>> jdk/test/java/rmi/testlibrary. It's been around for quite some time >>>> already, but I've been doing some maintenance on it recently. >>>> (Also, it still needs more work.) >>>> >>>> Since the RMI library is in the jdk repo and these test utilities are >>>> in hotspot, it seems like sharing of code might be difficult. >>>> But we might want to compare notes. Here are some observations and >>>> comments (though not an actual code review). >>>> >>>> * The use of a pair of threads (StreamPumper) to collect output from >>>> the subprocess is very similar to what RMI does. See the StreamPipe >>>> class in RMI's test library, which are used by the JavaVM utility >>>> class. One thing I did do recently was to make sure that the >>>> subprocess is waited for and the threads are joined. This hadn't been >>>> done before, leading to race conditions where some subprocess output >>>> was dropped. >>>> >>>> * Since these threads are specifically joined, I'm not sure of the >>>> utility of making them daemon threads. >>>> >>>> * My style in writing test code and test library code is to be quite >>>> verbose about everything and to check every possible error condition. >>>> Nothing is worse than seeing a test fail and not having enough >>>> information in the log to find out why. Actually, I can think of >>>> something worse: having a test pass erroneously because some error >>>> condition wasn't checked. (Yes, this has happened.) >>>> >>>> * Another style point is that I think it's OK for test library code >>>> just to throw exceptions out to the caller. My test code usually has >>>> 'throws IOException' or even 'throws Exception' on most of the >>>> methods, including main, so having test library code throw checked >>>> exceptions is reasonable. Jtreg will catch exceptions thrown from >>>> main and log them. Usually you want tests to fail quickly at the >>>> point of error. So, I concur with Vitaly's concern about ProcessTools >>>> handling of IOException and about letting interrupts propagate. >>>> >>>> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe >>>> threads to catch exceptions and report them back to their "parent" >>>> JavaVM. This is probably a rare occurrence but it does ensure that >>>> any errors that occur here won't go unnoticed. See >>>> JDK-8005827 ( >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >>>> >>>> * Regarding jtreg and test library code, it's pretty simple to use. >>>> In each test that uses the library code, one adds the @library tag to >>>> declare the library. It's probably a good idea to add an @build tag >>>> to build each library class that's used in the test. Things usually >>>> work in the absence of @build tags, because of implicit compilation, >>>> but it's kind of fragile. >>>> >>>> Anyway, I just wanted to share some notes and ideas. >>>> >>>> s'marks >>>> >>>> >>>> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> ? >>>>> >>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>> multi-process tests in jtreg, webrev can be found at >>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>> >>>>> ? >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * Give Rabbit time, and he'll always get the answer >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * Give Rabbit time, and he'll always get the answer From joe.darcy at oracle.com Thu Jan 17 10:34:00 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Jan 2013 10:34:00 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F83BBF.5000807@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> <50F82EAE.3020100@oracle.com> <50F83BBF.5000807@oracle.com> Message-ID: <50F84418.6070908@oracle.com> Dmitry, On 1/17/2013 9:58 AM, Dmitry Samersoff wrote: > Kelly, > > We have couple of platform depended points that makes shell tests not > reliable: > > 1. Getting PID of right process > 2. Kill running process > 3. Remove remaining locks and locked files/directories (e.g. hsperfdata) There are many more shell-specific problems too in terms of differences in what is accepted by the shell we run on different platforms, differences in behavior and location of commands, etc. > etc > > Java has all these problems as well, so I can't imagine why Java based > tests (I speak about multiprocess one only) is more reliable than shell > ones. Well, we the JDK group can and has written and shipped cross-platform functionality for such tasks as part of the JDK libraries. We should feel free to use that work in JDK testing too. -Joe > > The simplest way to improve reliability of shell based tests is write > different scripts for windows and for other platforms. > On my opinion most of problem with shell scripts is the result of > attempt to use unix style programming under windows. (e.g. tlist works > much better than ps from MKS or Cygwin) > > -Dmitry > > > On 2013-01-17 21:14, Kelly O'Hair wrote: >> Yes the devil is in shell scripts. Yes it's a pain to program client/server tests with pure Java, >> but with pure Java you can share that logic much safer than shell scripts. >> It's even more painful to get client/server tests to work reliably in shell scripts, on all platforms. >> >> Shell tests have been so problematic for so long that we need to start forcing the issue, >> 'no more shell tests' should now be the rule. >> Developers need to figure out how to share Java client/server logic between tests and stop adding >> more to this shell test nightmare. >> >> -kto >> >> On Jan 17, 2013, at 9:02 AM, Dmitry Samersoff wrote: >> >>> Joe, >>> >>> The devil is not in shell scripts. The devil is in the fact that >>> harness (jtreg) doesn't have a process management and doesn't support >>> client server tests. >>> >>> Shell initially designed to manage processes but java not, so replacing >>> shell scripts to java based process builder that exec java from within >>> java that exec another java doesn't make things better and just leads to >>> the new layer of errors. >>> >>> I guess we should invest some time and efforts to jtreg and finaly being >>> able to write something like (approximately) >>> >>> @run/server/timeout=300 someClass >>> @run/client someClass >>> >>> and then use >>> jtreg.getServerPid(), >>> jtreg.shutdownServer() >>> >>> etc. >>> >>> Then I vote with two hands for getting rid of all shell based tests. >>> >>> But today I see no benefits from replacing >>> >>> java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -version | >>> grep "warning: Using incremental CMS is deprecated" >>> >>> to a 16 lines of Java code ( >>> http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/test/gc/startup-warnings/TestCMSIncrementalMode.java.html >>> ) >>> >>> >>> -Dmitry >>> >>> >>> >>> >>> On 2013-01-17 20:34, Joe Darcy wrote: >>>> On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >>>>>> What is benefits of this library over usual shell script? >>>>> It works on all platforms, also the code is a lot cleaner and easier >>>>> to maintain. >>>> Shell tests are awful. We should strive to not only stop adding more >>>> shell tests, I think we should work to convert existing shell tests into >>>> Java programs. >>>> >>>> I've been looking a bit at the set of tests with transient failures are >>>> shell tests are overrepresented on that list. Writing cross platform >>>> shell code is tricky and the shells on some platforms have a history of >>>> being at least one of slow and unreliable. Additionally, the test >>>> themselves often have bugs. For example, Alan Bateman just recently >>>> pushed a changest to have the tests properly respect environment >>>> variables passed in by jtreg [1]. >>>> >>>> -Joe >>>> >>>> [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and >>>> other tools >>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 >>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff >>>>> Sent: den 17 januari 2013 15:59 >>>>> To: Christian T?rnqvist >>>>> Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>>>> multiprocess tests in jtreg >>>>> >>>>> On 2013-01-17 18:10, Christian T?rnqvist wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>>>> explaining how to use this tools. >>>>>> My intention is to write a detailed guide to writing jtreg tests, >>>>>> including the use of these (and future) utility classes. >>>>> Good. >>>>> >>>>>>> 2. Is it possible to create your own exception rather than use >>>>>>> Exceptioin class directly. >>>>>> I've changed it to use RuntimeException based on feedback from other >>>>>> people >>>>> Please create your own exception class. I would like to be able to >>>>> distinguish between exceptions that comes from different parts of tests. >>>>> >>>>>>> 3. Who is responsible to kill started process? >>>>>> This is really a task for the jtreg framework. Honestly it doesn't >>>>>> really do this very well right now, since the process handling in Java >>>>>> is not good enough to deal with this. I think this is a something we >>>>>> should look into addressing in jtreg rather than having the tests >>>>>> worry about it. >>>>> What is benefits of this library over usual shell script? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>>> Best regards, Christian >>>>>> >>>>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>>>> 2013 14:14 To: Coleen Phillimore Cc: >>>>>> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >>>>>> utility classes for writing better multiprocess tests in jtreg >>>>>> >>>>>> Christian, >>>>>> >>>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>>> explaining how to use this tools. >>>>>> >>>>>> >>>>>> 2. Is it possible to create your own exception rather than use >>>>>> Exceptioin class directly. >>>>>> >>>>>> >>>>>> 3. Who is responsible to kill started process? >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2013-01-16 17:53, Coleen Phillimore wrote: >>>>>>> Christian, Can you write up (somewhere!) what these are for and how >>>>>>> these are going to be used? I don't understand just from this >>>>>>> code. Does jtreg know enough to build these classfiles? Do we >>>>>>> have to write shell scripts to refer to these? Thanks, Coleen >>>>>>> >>>>>>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> >>>>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>>>> multi-process tests in jtreg, webrev can be found at >>>>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Christian >>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>>> Russia * Give Rabbit time, and he'll always get the answer >>>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * Give Rabbit time, and he'll always get the answer >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * Give Rabbit time, and he'll always get the answer > From kelly.ohair at oracle.com Thu Jan 17 11:35:54 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 17 Jan 2013 11:35:54 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F84418.6070908@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> <50F82EAE.3020100@oracle.com> <50F83BBF.5000807@oracle.com> <50F84418.6070908@oracle.com> Message-ID: On Jan 17, 2013, at 10:34 AM, Joe Darcy wrote: > Dmitry, > > On 1/17/2013 9:58 AM, Dmitry Samersoff wrote: >> Kelly, >> >> We have couple of platform depended points that makes shell tests not >> reliable: >> >> 1. Getting PID of right process >> 2. Kill running process >> 3. Remove remaining locks and locked files/directories (e.g. hsperfdata) > > There are many more shell-specific problems too in terms of differences in what is accepted by the shell we run on different platforms, differences in behavior and location of commands, etc. Yup, I agree with Joe. It's more than these 3 items. Shells are easily impacted by their environment. Java code is much more predictable, and we are delivering Java as a product, maybe we need to write more Java, and if this is hard to do, well, maybe that's a hint to us that we need to fix something. The old dog food test. ;^) > >> etc >> >> Java has all these problems as well, so I can't imagine why Java based >> tests (I speak about multiprocess one only) is more reliable than shell >> ones. > Yes, Java has issues too, I'm am not denying that. But Java can be debugged, is much more readable and easier to diagnose. It's a real language, and OUR language, we need to use it. -kto > Well, we the JDK group can and has written and shipped cross-platform functionality for such tasks as part of the JDK libraries. We should feel free to use that work in JDK testing too. > > -Joe > >> >> The simplest way to improve reliability of shell based tests is write >> different scripts for windows and for other platforms. >> On my opinion most of problem with shell scripts is the result of >> attempt to use unix style programming under windows. (e.g. tlist works >> much better than ps from MKS or Cygwin) >> >> -Dmitry >> >> >> On 2013-01-17 21:14, Kelly O'Hair wrote: >>> Yes the devil is in shell scripts. Yes it's a pain to program client/server tests with pure Java, >>> but with pure Java you can share that logic much safer than shell scripts. >>> It's even more painful to get client/server tests to work reliably in shell scripts, on all platforms. >>> >>> Shell tests have been so problematic for so long that we need to start forcing the issue, >>> 'no more shell tests' should now be the rule. >>> Developers need to figure out how to share Java client/server logic between tests and stop adding >>> more to this shell test nightmare. >>> >>> -kto >>> >>> On Jan 17, 2013, at 9:02 AM, Dmitry Samersoff wrote: >>> >>>> Joe, >>>> >>>> The devil is not in shell scripts. The devil is in the fact that >>>> harness (jtreg) doesn't have a process management and doesn't support >>>> client server tests. >>>> >>>> Shell initially designed to manage processes but java not, so replacing >>>> shell scripts to java based process builder that exec java from within >>>> java that exec another java doesn't make things better and just leads to >>>> the new layer of errors. >>>> >>>> I guess we should invest some time and efforts to jtreg and finaly being >>>> able to write something like (approximately) >>>> >>>> @run/server/timeout=300 someClass >>>> @run/client someClass >>>> >>>> and then use >>>> jtreg.getServerPid(), >>>> jtreg.shutdownServer() >>>> >>>> etc. >>>> >>>> Then I vote with two hands for getting rid of all shell based tests. >>>> >>>> But today I see no benefits from replacing >>>> >>>> java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -version | >>>> grep "warning: Using incremental CMS is deprecated" >>>> >>>> to a 16 lines of Java code ( >>>> http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/test/gc/startup-warnings/TestCMSIncrementalMode.java.html >>>> ) >>>> >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> >>>> On 2013-01-17 20:34, Joe Darcy wrote: >>>>> On 1/17/2013 7:15 AM, Christian T?rnqvist wrote: >>>>>>> What is benefits of this library over usual shell script? >>>>>> It works on all platforms, also the code is a lot cleaner and easier >>>>>> to maintain. >>>>> Shell tests are awful. We should strive to not only stop adding more >>>>> shell tests, I think we should work to convert existing shell tests into >>>>> Java programs. >>>>> >>>>> I've been looking a bit at the set of tests with transient failures are >>>>> shell tests are overrepresented on that list. Writing cross platform >>>>> shell code is tricky and the shells on some platforms have a history of >>>>> being at least one of slow and unreliable. Additionally, the test >>>>> themselves often have bugs. For example, Alan Bateman just recently >>>>> pushed a changest to have the tests properly respect environment >>>>> variables passed in by jtreg [1]. >>>>> >>>>> -Joe >>>>> >>>>> [1] 8005978: shell tests need to use the $COMPILEJDK for javac, jar and >>>>> other tools >>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 >>>>> >>>>>> Thanks, >>>>>> Christian >>>>>> >>>>>> -----Original Message----- >>>>>> From: Dmitry Samersoff >>>>>> Sent: den 17 januari 2013 15:59 >>>>>> To: Christian T?rnqvist >>>>>> Cc: Coleen Phillimore; hotspot-dev at openjdk.java.net >>>>>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>>>>> multiprocess tests in jtreg >>>>>> >>>>>> On 2013-01-17 18:10, Christian T?rnqvist wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>>>>> explaining how to use this tools. >>>>>>> My intention is to write a detailed guide to writing jtreg tests, >>>>>>> including the use of these (and future) utility classes. >>>>>> Good. >>>>>> >>>>>>>> 2. Is it possible to create your own exception rather than use >>>>>>>> Exceptioin class directly. >>>>>>> I've changed it to use RuntimeException based on feedback from other >>>>>>> people >>>>>> Please create your own exception class. I would like to be able to >>>>>> distinguish between exceptions that comes from different parts of tests. >>>>>> >>>>>>>> 3. Who is responsible to kill started process? >>>>>>> This is really a task for the jtreg framework. Honestly it doesn't >>>>>>> really do this very well right now, since the process handling in Java >>>>>>> is not good enough to deal with this. I think this is a something we >>>>>>> should look into addressing in jtreg rather than having the tests >>>>>>> worry about it. >>>>>> What is benefits of this library over usual shell script? >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>>> Best regards, Christian >>>>>>> >>>>>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>>>>> 2013 14:14 To: Coleen Phillimore Cc: >>>>>>> hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add >>>>>>> utility classes for writing better multiprocess tests in jtreg >>>>>>> >>>>>>> Christian, >>>>>>> >>>>>>> 1. I'm second to Coleen. Is it possible to add more comments >>>>>>> explaining how to use this tools. >>>>>>> >>>>>>> >>>>>>> 2. Is it possible to create your own exception rather than use >>>>>>> Exceptioin class directly. >>>>>>> >>>>>>> >>>>>>> 3. Who is responsible to kill started process? >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2013-01-16 17:53, Coleen Phillimore wrote: >>>>>>>> Christian, Can you write up (somewhere!) what these are for and how >>>>>>>> these are going to be used? I don't understand just from this >>>>>>>> code. Does jtreg know enough to build these classfiles? Do we >>>>>>>> have to write shell scripts to refer to these? Thanks, Coleen >>>>>>>> >>>>>>>> On 1/16/2013 7:34 AM, Christian T?rnqvist wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> >>>>>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>>>>> multi-process tests in jtreg, webrev can be found at >>>>>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Christian >>>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>>>> Russia * Give Rabbit time, and he'll always get the answer >>>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * Give Rabbit time, and he'll always get the answer >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * Give Rabbit time, and he'll always get the answer >> > From jonathan.gibbons at oracle.com Thu Jan 17 09:23:23 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 Jan 2013 09:23:23 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> Message-ID: <50F8338B.6020104@oracle.com> I think there's a confusion here between an external dependency on the test harness (which has generally been deemed acceptable) and a potentially new external dependencies on test libraries in other repositories in the forest, which would see less acceptable to me. There /are/ times when cut-n-paste is the correct solution. :-) -- Jon On 01/17/2013 09:17 AM, Kelly O'Hair wrote: > The C compiler, bash, libraries, unix utilities, aren't in the repo. We will have and always have > external dependencies. I agree we need to limit them, but a testing harness (ideally one) is a very > valid external dependency to have. > > Hotspot needs to get lined up with the standard jdk testing, jtreg is already used in jdk, JPRT, > QE teams, and many developers are very familiar with it. > > -kto > > On Jan 17, 2013, at 6:10 AM, Christian T?rnqvist wrote: > >> Well, jtreg is not in the hotspot repo (and shouldn't be) and suddenly you end up having an external dependency. I'd like to keep the tests free from dependence on jtreg (along with other external resources). >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: den 17 januari 2013 15:06 >> To: Christian T?rnqvist >> Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg >> >> Christian, >> >> On my opinion something like >> >> import com.oracle.jtreg.tools.* >> >> is less painful than maintain several independent implementations of the same ideas. >> >> -Dmitry >> >> >> On 2013-01-17 18:01, Christian T?rnqvist wrote: >>>> Is it possible to have a library like this one included into jtreg >>>> and available for everybody ? >>> The problem with this is that suddenly the tests have a dependency on >>> jtreg. One (of many) nice things with the jtreg tests is that they can >>> be run as a normal java program without the need to involve jtreg, >>> making debugging and troubleshooting them a lot easier. >>> >>> Best regards, Christian >>> >>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>> 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; >>> hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): >>> 8006413: Add utility classes for writing better multiprocess tests in >>> jtreg >>> >>> Stuart, >>> >>>> I work on the JDK core libraries. It turns out that there is a >>>> similar library used for testing RMI. >>> I guess if we take close look to exising tests we would find couple >>> more copies of the same ideas. >>> >>> Is it possible to have a library like this one included into jtreg and >>> available for everybody ? >>> >>> -Dmitry >>> >>> >>> On 2013-01-17 01:54, Stuart Marks wrote: >>>> Hi everybody, >>>> >>>> I work on the JDK core libraries. It turns out that there is a >>>> similar library used for testing RMI. Take a look at >>>> jdk/test/java/rmi/testlibrary. It's been around for quite some time >>>> already, but I've been doing some maintenance on it recently. >>>> (Also, it still needs more work.) >>>> >>>> Since the RMI library is in the jdk repo and these test utilities are >>>> in hotspot, it seems like sharing of code might be difficult. >>>> But we might want to compare notes. Here are some observations and >>>> comments (though not an actual code review). >>>> >>>> * The use of a pair of threads (StreamPumper) to collect output from >>>> the subprocess is very similar to what RMI does. See the StreamPipe >>>> class in RMI's test library, which are used by the JavaVM utility >>>> class. One thing I did do recently was to make sure that the >>>> subprocess is waited for and the threads are joined. This hadn't been >>>> done before, leading to race conditions where some subprocess output >>>> was dropped. >>>> >>>> * Since these threads are specifically joined, I'm not sure of the >>>> utility of making them daemon threads. >>>> >>>> * My style in writing test code and test library code is to be quite >>>> verbose about everything and to check every possible error condition. >>>> Nothing is worse than seeing a test fail and not having enough >>>> information in the log to find out why. Actually, I can think of >>>> something worse: having a test pass erroneously because some error >>>> condition wasn't checked. (Yes, this has happened.) >>>> >>>> * Another style point is that I think it's OK for test library code >>>> just to throw exceptions out to the caller. My test code usually has >>>> 'throws IOException' or even 'throws Exception' on most of the >>>> methods, including main, so having test library code throw checked >>>> exceptions is reasonable. Jtreg will catch exceptions thrown from >>>> main and log them. Usually you want tests to fail quickly at the >>>> point of error. So, I concur with Vitaly's concern about ProcessTools >>>> handling of IOException and about letting interrupts propagate. >>>> >>>> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe >>>> threads to catch exceptions and report them back to their "parent" >>>> JavaVM. This is probably a rare occurrence but it does ensure that >>>> any errors that occur here won't go unnoticed. See >>>> JDK-8005827 ( >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >>>> >>>> * Regarding jtreg and test library code, it's pretty simple to use. >>>> In each test that uses the library code, one adds the @library tag to >>>> declare the library. It's probably a good idea to add an @build tag >>>> to build each library class that's used in the test. Things usually >>>> work in the absence of @build tags, because of implicit compilation, >>>> but it's kind of fragile. >>>> >>>> Anyway, I just wanted to share some notes and ideas. >>>> >>>> s'marks >>>> >>>> >>>> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> ? >>>>> >>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>> multi-process tests in jtreg, webrev can be found at >>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>> >>>>> ? >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * Give Rabbit time, and he'll always get the answer >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * Give Rabbit time, and he'll always get the answer From jonathan.gibbons at oracle.com Thu Jan 17 10:10:03 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 Jan 2013 10:10:03 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F834D2.60304@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F72181.7080307@oracle.com> <50F7FA9B.40101@oracle.com> <50F80541.9080006@oracle.com> <472FE042-ED92-449F-8DCB-8E721AB75954@oracle.com> <50F8338B.6020104@oracle.com> <50F834D2.60304@oracle.com> Message-ID: <50F83E7B.4090807@oracle.com> That does not sound like a viable solution to me. We should not have test code in the test harness -- we will have too much trouble synchronizing the right version of the harness with the tests. We need a greater separation between the harness and the tests. -- Jon On 01/17/2013 09:28 AM, Dmitry Samersoff wrote: > Jonathan, > > Just to clarify, I propose: > > 1. Add TestTools directory to JTREG workspace. > 2. Build TestTools.jar together with jtreg > 3. Maintain and distribute TestTools.jar together with > jtreg under jtreg policies. > 4. Add /TestTools.jar to default classpath for > all tests. > 5. Use import com.oracle.jtreg.tools.* when necessary. > > -Dmitry > > > > On 2013-01-17 21:23, Jonathan Gibbons wrote: >> I think there's a confusion here between an external dependency on the >> test harness (which has generally been deemed acceptable) and a >> potentially new external dependencies on test libraries in other >> repositories in the forest, which would see less acceptable to me. >> >> There /are/ times when cut-n-paste is the correct solution. :-) >> >> -- Jon >> >> On 01/17/2013 09:17 AM, Kelly O'Hair wrote: >>> The C compiler, bash, libraries, unix utilities, aren't in the repo. >>> We will have and always have >>> external dependencies. I agree we need to limit them, but a testing >>> harness (ideally one) is a very >>> valid external dependency to have. >>> >>> Hotspot needs to get lined up with the standard jdk testing, jtreg is >>> already used in jdk, JPRT, >>> QE teams, and many developers are very familiar with it. >>> >>> -kto >>> >>> On Jan 17, 2013, at 6:10 AM, Christian T?rnqvist wrote: >>> >>>> Well, jtreg is not in the hotspot repo (and shouldn't be) and >>>> suddenly you end up having an external dependency. I'd like to keep >>>> the tests free from dependence on jtreg (along with other external >>>> resources). >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Dmitry Samersoff >>>> Sent: den 17 januari 2013 15:06 >>>> To: Christian T?rnqvist >>>> Cc: Stuart Marks; hotspot-dev at openjdk.java.net; Jonathan Gibbons >>>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>>> multiprocess tests in jtreg >>>> >>>> Christian, >>>> >>>> On my opinion something like >>>> >>>> import com.oracle.jtreg.tools.* >>>> >>>> is less painful than maintain several independent implementations of >>>> the same ideas. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2013-01-17 18:01, Christian T?rnqvist wrote: >>>>>> Is it possible to have a library like this one included into jtreg >>>>>> and available for everybody ? >>>>> The problem with this is that suddenly the tests have a dependency on >>>>> jtreg. One (of many) nice things with the jtreg tests is that they can >>>>> be run as a normal java program without the need to involve jtreg, >>>>> making debugging and troubleshooting them a lot easier. >>>>> >>>>> Best regards, Christian >>>>> >>>>> -----Original Message----- From: Dmitry Samersoff Sent: den 17 januari >>>>> 2013 14:20 To: Stuart Marks Cc: Christian T?rnqvist; >>>>> hotspot-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR (S): >>>>> 8006413: Add utility classes for writing better multiprocess tests in >>>>> jtreg >>>>> >>>>> Stuart, >>>>> >>>>>> I work on the JDK core libraries. It turns out that there is a >>>>>> similar library used for testing RMI. >>>>> I guess if we take close look to exising tests we would find couple >>>>> more copies of the same ideas. >>>>> >>>>> Is it possible to have a library like this one included into jtreg and >>>>> available for everybody ? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-01-17 01:54, Stuart Marks wrote: >>>>>> Hi everybody, >>>>>> >>>>>> I work on the JDK core libraries. It turns out that there is a >>>>>> similar library used for testing RMI. Take a look at >>>>>> jdk/test/java/rmi/testlibrary. It's been around for quite some time >>>>>> already, but I've been doing some maintenance on it recently. >>>>>> (Also, it still needs more work.) >>>>>> >>>>>> Since the RMI library is in the jdk repo and these test utilities are >>>>>> in hotspot, it seems like sharing of code might be difficult. >>>>>> But we might want to compare notes. Here are some observations and >>>>>> comments (though not an actual code review). >>>>>> >>>>>> * The use of a pair of threads (StreamPumper) to collect output from >>>>>> the subprocess is very similar to what RMI does. See the StreamPipe >>>>>> class in RMI's test library, which are used by the JavaVM utility >>>>>> class. One thing I did do recently was to make sure that the >>>>>> subprocess is waited for and the threads are joined. This hadn't been >>>>>> done before, leading to race conditions where some subprocess output >>>>>> was dropped. >>>>>> >>>>>> * Since these threads are specifically joined, I'm not sure of the >>>>>> utility of making them daemon threads. >>>>>> >>>>>> * My style in writing test code and test library code is to be quite >>>>>> verbose about everything and to check every possible error condition. >>>>>> Nothing is worse than seeing a test fail and not having enough >>>>>> information in the log to find out why. Actually, I can think of >>>>>> something worse: having a test pass erroneously because some error >>>>>> condition wasn't checked. (Yes, this has happened.) >>>>>> >>>>>> * Another style point is that I think it's OK for test library code >>>>>> just to throw exceptions out to the caller. My test code usually has >>>>>> 'throws IOException' or even 'throws Exception' on most of the >>>>>> methods, including main, so having test library code throw checked >>>>>> exceptions is reasonable. Jtreg will catch exceptions thrown from >>>>>> main and log them. Usually you want tests to fail quickly at the >>>>>> point of error. So, I concur with Vitaly's concern about ProcessTools >>>>>> handling of IOException and about letting interrupts propagate. >>>>>> >>>>>> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe >>>>>> threads to catch exceptions and report them back to their "parent" >>>>>> JavaVM. This is probably a rare occurrence but it does ensure that >>>>>> any errors that occur here won't go unnoticed. See >>>>>> JDK-8005827 ( >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827 ) >>>>>> >>>>>> * Regarding jtreg and test library code, it's pretty simple to use. >>>>>> In each test that uses the library code, one adds the @library tag to >>>>>> declare the library. It's probably a good idea to add an @build tag >>>>>> to build each library class that's used in the test. Things usually >>>>>> work in the absence of @build tags, because of implicit compilation, >>>>>> but it's kind of fragile. >>>>>> >>>>>> Anyway, I just wanted to share some notes and ideas. >>>>>> >>>>>> s'marks >>>>>> >>>>>> >>>>>> On 1/16/13 4:34 AM, Christian T?rnqvist wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> This RFE adds a few utility classes to make it a bit easier to write >>>>>>> multi-process tests in jtreg, webrev can be found at >>>>>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Christian >>>>>>> >>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>> Russia * Give Rabbit time, and he'll always get the answer >>>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * Give Rabbit time, and he'll always get the answer > From dean.long at oracle.com Thu Jan 17 18:23:17 2013 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 18 Jan 2013 02:23:17 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130118022328.509764739B@hg.openjdk.java.net> Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp From alejandro.murillo at oracle.com Thu Jan 17 20:55:23 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 18 Jan 2013 04:55:23 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130118045538.F398C473A1@hg.openjdk.java.net> Changeset: 23867f4f4480 Author: katleman Date: 2013-01-16 13:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/23867f4f4480 Added tag jdk7u14-b10 for changeset 181528fd1e74 ! .hgtags Changeset: 4008cf63c301 Author: amurillo Date: 2013-01-17 03:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4008cf63c301 Merge - src/share/vm/trace/traceEventTypes.hpp Changeset: 06a41c6e29c2 Author: amurillo Date: 2013-01-17 03:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/06a41c6e29c2 Added tag hs24-b30 for changeset 4008cf63c301 ! .hgtags From vladimir.kozlov at oracle.com Thu Jan 17 21:10:15 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 18 Jan 2013 05:10:15 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130118051037.79257473A3@hg.openjdk.java.net> Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp From alejandro.murillo at oracle.com Fri Jan 18 01:19:25 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 18 Jan 2013 09:19:25 +0000 Subject: hg: hsx/hsx24/hotspot: 8006510: new hotspot build - hs24-b31 Message-ID: <20130118091931.4EE4C473AC@hg.openjdk.java.net> Changeset: 3ccedb5838f2 Author: amurillo Date: 2013-01-17 03:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3ccedb5838f2 8006510: new hotspot build - hs24-b31 Reviewed-by: jcoomes ! make/hotspot_version From alejandro.murillo at oracle.com Fri Jan 18 02:56:26 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 18 Jan 2013 03:56:26 -0700 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> Message-ID: <50F92A5A.4090000@oracle.com> Hi Chris (Phillips) I just got a snapshot of hs24 and bumped the build number to b31, so we can resume pushing bug fixes to it. Unfortunately the patch in the webrev at [1] does not apply cleanly anymore, Can you guys reapply the changes to clean clone of [2] and send the new webrev? Then if the previous reviewers approve it, I will push that soon after so it makes it into next week snapshot. Apologies for the extra work [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot Thanks Alejandro On 1/2/2013 1:02 PM, Christian Thalinger wrote: > On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T O wrote: > >> Hi Alejandro, >> Oops emails crossed in the net ... >> See my latest email , I had to regenerate the webrev and patch - >> This webrev s/b ok: >> >> Webrev: >> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > That looks good. -- Chris > >> Chris >> >> On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >>> Hi Chris, >>> In that case is not necessary. >>> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >>> but looks like it is against hsx/hsx24/hotspot. >>> BTW, I went to check the webrev link and is unreachable, can you check >>> that? >>> Thanks >>> Alejandro >>> >>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>>> Hi Alejandro, >>>> >>>> The only change since I tested this afternoon is the change >>>> for the hotspot_version. I will re-run tests if you wish but it seems >>>> unnecessary. >>>> >>>> Cheers! >>>> Chris >>>> >>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>>> Hi >>>>>> >>>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>>> sponsor >>>>>> - Twisti ? } >>>>>> >>>>>> Attached is a backport (essentially resurrection of the Permgen code) >>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and built >>>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>>> >>>>>> Please review. >>>>>> >>>>>> Cheers! >>>>>> Chris >>>>>> PS >>>>>> Webrev is here: >>>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ >>>>>> >>>>> Hi >>>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>>> Can you rework the patch/webrev against this repo: >>>>> >>>>> http://hg.openjdk.java.net/hsx/hsx24/hotspot >>>>> >>>>> once it's reviewed I can push it >>>>> >>>>> Thanks >>>>> >>> From christian.tornqvist at oracle.com Fri Jan 18 04:43:49 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Fri, 18 Jan 2013 04:43:49 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> Message-ID: <6a817e45-1150-411d-94b6-560c016b3353@default> Another updated webrev at http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , formatting changes. Thanks, Christian -----Original Message----- From: Christian T?rnqvist Sent: den 17 januari 2013 17:44 To: hotspot-dev at openjdk.java.net Cc: Vitaly Davidovich; Yekaterina Kantserova Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Updated webrev can be found at http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots of small changes based on all the great feedback I got :) Thanks, Christian -----Original Message----- From: Christian T?rnqvist Sent: den 17 januari 2013 15:19 To: Vitaly Davidovich Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Hi Vitaly, First of all, thanks for all your feedback :) >- not entirely sure what getPlatformSpecificVMArgs is really meant for.? Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra >braces) This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. >- there's no non-reflective way to get the pid? Not that I've found :( ? I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: den 16 januari 2013 16:30 To: Christian T?rnqvist Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Some of this is style so feel free to ignore: I'd mark all these classes final for now.? I'd also hide the default ctor for the util classes that only have static methods. JDKToolFinder - Check that the jdk.test sysprop is not empty as well. - Remove the throws clause from the method - don't think it adds any value. - RuntimeException seems more idiomatic instead of Exception - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here).? Perhaps even return a File or Path instance instead of string. OutputAnalyzer - any reason fields are default visible? Make them private and final. - should probably check that output is not null in the constructors - it's possible to chain the constructors here - same comment about throws clauses on methods + RuntimeException as above ProcessTools - getOutput swallows IOException and returns "".? Not sure this is best - I think the test should fail as you can't trust the results at this point. - StreamPumper extends Thread so I don't think you need the wrapper threads here.? Cleaner is to make StreamPumper implement Runnable though and use threads here. - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate.? I'd let the interrupt bubble up. - there's no non-reflective way to get the pid? - not entirely sure what getPlatformSpecificVMArgs is really meant for.? Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. StreamPumper - check ctor args for null reference.? The fields can be final as well. That's all for now :). Thanks Sent from my phone On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: Hi Vitaly, ? Setting them as daemon sounds like a good idea :) ? I'd like your feedback on the other things as well, the quality of test code is important. ? Thanks, Christian ? From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" \nvitalyd at gmail.com] Sent: den 16 januari 2013 14:50 To: Christian T?rnqvist Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" \nhotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg ? Hi Christian, Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. There are some other things that can be done, but not sure it's worth the effort for a testing utility.? Let me know though if you'd like to cover everything. Thanks Sent from my phone On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: Hi everyone, ? This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ ? Thanks, Christian From bengt.rutisson at oracle.com Fri Jan 18 04:49:41 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Jan 2013 13:49:41 +0100 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <6a817e45-1150-411d-94b6-560c016b3353@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> Message-ID: <50F944E5.1060609@oracle.com> Looks good. Bengt On 1/18/13 1:43 PM, Christian T?rnqvist wrote: > Another updated webrev at http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , formatting changes. > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 17:44 > To: hotspot-dev at openjdk.java.net > Cc: Vitaly Davidovich; Yekaterina Kantserova > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Updated webrev can be found at http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots of small changes based on all the great feedback I got :) > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 15:19 > To: Vitaly Davidovich > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Hi Vitaly, > > First of all, thanks for all your feedback :) > >> - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra >braces) > This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. > >> - there's no non-reflective way to get the pid? > Not that I've found :( > > > > I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: den 16 januari 2013 16:30 > To: Christian T?rnqvist > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > > > Some of this is style so feel free to ignore: > > I'd mark all these classes final for now. I'd also hide the default ctor for the util classes that only have static methods. > > JDKToolFinder > - Check that the jdk.test sysprop is not empty as well. > > - Remove the throws clause from the method - don't think it adds any value. > > - RuntimeException seems more idiomatic instead of Exception > > - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here). Perhaps even return a File or Path instance instead of string. > > OutputAnalyzer > - any reason fields are default visible? Make them private and final. > > - should probably check that output is not null in the constructors > > - it's possible to chain the constructors here > > - same comment about throws clauses on methods + RuntimeException as above > > ProcessTools > - getOutput swallows IOException and returns "". Not sure this is best - I think the test should fail as you can't trust the results at this point. > > - StreamPumper extends Thread so I don't think you need the wrapper threads here. Cleaner is to make StreamPumper implement Runnable though and use threads here. > > - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate. I'd let the interrupt bubble up. > > - there's no non-reflective way to get the pid? > > - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) > > -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. > > StreamPumper > - check ctor args for null reference. The fields can be final as well. > > That's all for now :). > > Thanks > Sent from my phone > > On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: > > Hi Vitaly, > > > > Setting them as daemon sounds like a good idea :) > > > > I'd like your feedback on the other things as well, the quality of test code is important. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" \nvitalyd at gmail.com] > Sent: den 16 januari 2013 14:50 > To: Christian T?rnqvist > Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" \nhotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > > > Hi Christian, > > Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. > > There are some other things that can be done, but not sure it's worth the effort for a testing utility. Let me know though if you'd like to cover everything. > > Thanks > > Sent from my phone > > On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: > > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian From bengt.rutisson at oracle.com Fri Jan 18 04:57:00 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 18 Jan 2013 12:57:00 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20130118125718.EEEFA473B7@hg.openjdk.java.net> Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp From vladimir.x.ivanov at oracle.com Fri Jan 18 06:18:33 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2013 17:18:33 +0300 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <6a817e45-1150-411d-94b6-560c016b3353@default> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> Message-ID: <50F959B9.4070204@oracle.com> Christian, Nice work! Thanks for adding this. I have a couple of comments. Don't consider me too paranoic, please :-) test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: 60 public static String getOutput(Process process) throws IOException { 61 ByteArrayOutputStream buf = new ByteArrayOutputStream(); 62 StreamPumper outPumper = new StreamPumper(process.getInputStream(), buf); 63 StreamPumper errPumper = new StreamPumper(process.getErrorStream(), buf); stdout & stderr are stored in the same buffer. I don't see why the output can't be interleaved, so consequent analysis could fail intermittently. I suggest to store and analyze them separately. Also, it'll allow to limit the search to concrete stream. In the following code: test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: 54 public void run() { 55 int length; 56 try { 57 byte[] buffer = new byte[BUF_SIZE]; 58 InputStream localIn = in; 59 OutputStream localOut = out; 60 while ((length = localIn.read(buffer)) > 0 && !Thread.interrupted()) { 61 localOut.write(buffer, 0, length); 62 } 63 localOut.flush(); 64 } catch (IOException e) { 65 // Just abort if something like this happens. 66 e.printStackTrace(); 67 } 68 } Thread.interrupted call is redundant: if the thread is interrupted, exception will be thrown from localIn.read call anyway. Also, I would suggest to move localOut.flush to finally clause, since the call can be skipped in case of thread interruption. Best regards, Vladimir Ivanov On 1/18/13 3:43 PM, Christian T?rnqvist wrote: > Another updated webrev at http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , formatting changes. > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 17:44 > To: hotspot-dev at openjdk.java.net > Cc: Vitaly Davidovich; Yekaterina Kantserova > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Updated webrev can be found at http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots of small changes based on all the great feedback I got :) > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 15:19 > To: Vitaly Davidovich > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > Hi Vitaly, > > First of all, thanks for all your feedback :) > >> - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra >braces) > > This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. > >> - there's no non-reflective way to get the pid? > > Not that I've found :( > > > > I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: den 16 januari 2013 16:30 > To: Christian T?rnqvist > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > > > Some of this is style so feel free to ignore: > > I'd mark all these classes final for now. I'd also hide the default ctor for the util classes that only have static methods. > > JDKToolFinder > - Check that the jdk.test sysprop is not empty as well. > > - Remove the throws clause from the method - don't think it adds any value. > > - RuntimeException seems more idiomatic instead of Exception > > - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here). Perhaps even return a File or Path instance instead of string. > > OutputAnalyzer > - any reason fields are default visible? Make them private and final. > > - should probably check that output is not null in the constructors > > - it's possible to chain the constructors here > > - same comment about throws clauses on methods + RuntimeException as above > > ProcessTools > - getOutput swallows IOException and returns "". Not sure this is best - I think the test should fail as you can't trust the results at this point. > > - StreamPumper extends Thread so I don't think you need the wrapper threads here. Cleaner is to make StreamPumper implement Runnable though and use threads here. > > - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate. I'd let the interrupt bubble up. > > - there's no non-reflective way to get the pid? > > - not entirely sure what getPlatformSpecificVMArgs is really meant for. Maybe just have an is64bitJVM() instead? You can just return "new String[0]" though (I'm not a fan of extra braces) > > -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. > > StreamPumper > - check ctor args for null reference. The fields can be final as well. > > That's all for now :). > > Thanks > Sent from my phone > > On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: > > Hi Vitaly, > > > > Setting them as daemon sounds like a good idea :) > > > > I'd like your feedback on the other things as well, the quality of test code is important. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" \nvitalyd at gmail.com] > Sent: den 16 januari 2013 14:50 > To: Christian T?rnqvist > Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" \nhotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg > > > > Hi Christian, > > Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. > > There are some other things that can be done, but not sure it's worth the effort for a testing utility. Let me know though if you'd like to cover everything. > > Thanks > > Sent from my phone > > On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: > > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write multi-process tests in jtreg, webrev can be found at http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian > From vladimir.x.ivanov at oracle.com Fri Jan 18 06:23:23 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Jan 2013 17:23:23 +0300 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F959B9.4070204@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> Message-ID: <50F95ADB.3010304@oracle.com> Hit "Send" too early... One more comment: I don't see where you close streams acquired from Process.getOutputStream()/Process.getErrorStream(). Is it overlooked? Best regards, Vladimir Ivanov On 1/18/13 5:18 PM, Vladimir Ivanov wrote: > Christian, > > Nice work! Thanks for adding this. > > I have a couple of comments. Don't consider me too paranoic, please :-) > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: > 60 public static String getOutput(Process process) throws > IOException { > 61 ByteArrayOutputStream buf = new ByteArrayOutputStream(); > 62 StreamPumper outPumper = new > StreamPumper(process.getInputStream(), buf); > 63 StreamPumper errPumper = new > StreamPumper(process.getErrorStream(), buf); > > stdout & stderr are stored in the same buffer. I don't see why the > output can't be interleaved, so consequent analysis could fail > intermittently. I suggest to store and analyze them separately. Also, > it'll allow to limit the search to concrete stream. > > In the following code: > test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: > 54 public void run() { > 55 int length; > 56 try { > 57 byte[] buffer = new byte[BUF_SIZE]; > 58 InputStream localIn = in; > 59 OutputStream localOut = out; > 60 while ((length = localIn.read(buffer)) > 0 && > !Thread.interrupted()) { > 61 localOut.write(buffer, 0, length); > 62 } > 63 localOut.flush(); > 64 } catch (IOException e) { > 65 // Just abort if something like this happens. > 66 e.printStackTrace(); > 67 } > 68 } > > Thread.interrupted call is redundant: if the thread is interrupted, > exception will be thrown from localIn.read call anyway. > > Also, I would suggest to move localOut.flush to finally clause, since > the call can be skipped in case of thread interruption. > > Best regards, > Vladimir Ivanov > > On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >> Another updated webrev at >> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >> formatting changes. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 17:44 >> To: hotspot-dev at openjdk.java.net >> Cc: Vitaly Davidovich; Yekaterina Kantserova >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Updated webrev can be found at >> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots >> of small changes based on all the great feedback I got :) >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 15:19 >> To: Vitaly Davidovich >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Hi Vitaly, >> >> First of all, thanks for all your feedback :) >> >>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>> for. Maybe just have an is64bitJVM() instead? You can just return >>> "new String[0]" though (I'm not a fan of extra >braces) >> >> This is for dealing with platform specific arguments to the java >> launcher (more importantly, not having the test worry about these >> things). Right now we only have the requirement to send '-d64' to any >> process launched as 64bit on Solaris, in the future we might have >> other requirements. That's the reason for giving this a more general >> name. >> >>> - there's no non-reflective way to get the pid? >> >> Not that I've found :( >> >> >> >> I've taken a lot of your comments and made changes to the classes, >> I'll be publishing an updated webrev soon. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: den 16 januari 2013 16:30 >> To: Christian T?rnqvist >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Some of this is style so feel free to ignore: >> >> I'd mark all these classes final for now. I'd also hide the default >> ctor for the util classes that only have static methods. >> >> JDKToolFinder >> - Check that the jdk.test sysprop is not empty as well. >> >> - Remove the throws clause from the method - don't think it adds any >> value. >> >> - RuntimeException seems more idiomatic instead of Exception >> >> - after creating the full path string, might be nice to verify that it >> exists and throw if not (things will not work later but you can >> provide a better error message here). Perhaps even return a File or >> Path instance instead of string. >> >> OutputAnalyzer >> - any reason fields are default visible? Make them private and final. >> >> - should probably check that output is not null in the constructors >> >> - it's possible to chain the constructors here >> >> - same comment about throws clauses on methods + RuntimeException as >> above >> >> ProcessTools >> - getOutput swallows IOException and returns "". Not sure this is >> best - I think the test should fail as you can't trust the results at >> this point. >> >> - StreamPumper extends Thread so I don't think you need the wrapper >> threads here. Cleaner is to make StreamPumper implement Runnable >> though and use threads here. >> >> - interruption is caught and restored but no guarantee caller will >> observe it now. Again, don't think returning "" is right as results >> are indeterminate. I'd let the interrupt bubble up. >> >> - there's no non-reflective way to get the pid? >> >> - not entirely sure what getPlatformSpecificVMArgs is really meant >> for. Maybe just have an is64bitJVM() instead? You can just return >> "new String[0]" though (I'm not a fan of extra braces) >> >> -createJavaProcessBuilder() can probably just use >> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >> >> StreamPumper >> - check ctor args for null reference. The fields can be final as well. >> >> That's all for now :). >> >> Thanks >> Sent from my phone >> >> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.com> >> wrote: >> >> Hi Vitaly, >> >> >> >> Setting them as daemon sounds like a good idea :) >> >> >> >> I'd like your feedback on the other things as well, the quality of >> test code is important. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >> \nvitalyd at gmail.com] >> Sent: den 16 januari 2013 14:50 >> To: Christian T?rnqvist >> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >> \nhotspot-dev at openjdk.java.net >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Hi Christian, >> >> Not sure how polished you want/need this code to be since it's just >> utility, but one thing that jumped out was the stream pumper threads >> for reading stdout/err should be daemonized just to play it safe. >> >> There are some other things that can be done, but not sure it's worth >> the effort for a testing utility. Let me know though if you'd like to >> cover everything. >> >> Thanks >> >> Sent from my phone >> >> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com" >> \nchristian.tornqvist at oracle.com> wrote: >> >> Hi everyone, >> >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> >> >> Thanks, >> >> Christian >> From alejandro.murillo at oracle.com Fri Jan 18 08:05:33 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 18 Jan 2013 16:05:33 +0000 Subject: hg: hsx/hsx25/hotspot: 42 new changesets Message-ID: <20130118160701.AFC76473C2@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1a3e54283c54 Merge ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/97ee8abd6ab2 Merge Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/90a92d5bca17 Merge Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags From ChrisPhi at LGonQn.Org Fri Jan 18 08:37:33 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Fri, 18 Jan 2013 11:37:33 -0500 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: <50F92A5A.4090000@oracle.com> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> Message-ID: <50F97A4D.50606@LGonQn.Org> Hi Alejandro, Have updated the webrev (just off by one line in 1 file) and built both normal hotspot and zero on x86_64 based on the hsx24 repo head: http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/ [Also now contains updated copyrights] Cheers! Chris On 18/01/13 05:56 AM, Alejandro E Murillo wrote: > > Hi Chris (Phillips) > I just got a snapshot of hs24 and bumped the build number to b31, > so we can resume pushing bug fixes to it. > Unfortunately the patch in the webrev at [1] does not apply cleanly > anymore, > Can you guys reapply the changes to clean clone of [2] and send the > new webrev? > Then if the previous reviewers approve it, I will push that soon > after so it makes > it into next week snapshot. Apologies for the extra work > > [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot > > > > Thanks > Alejandro > > > On 1/2/2013 1:02 PM, Christian Thalinger wrote: >> On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T >> O wrote: >> >>> Hi Alejandro, >>> Oops emails crossed in the net ... >>> See my latest email , I had to regenerate the webrev and patch - >>> This webrev s/b ok: >>> >>> Webrev: >>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ >>> >> That looks good. -- Chris >> >>> Chris >>> >>> On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >>>> Hi Chris, >>>> In that case is not necessary. >>>> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >>>> but looks like it is against hsx/hsx24/hotspot. >>>> BTW, I went to check the webrev link and is unreachable, can you check >>>> that? >>>> Thanks >>>> Alejandro >>>> >>>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>>>> Hi Alejandro, >>>>> >>>>> The only change since I tested this afternoon is the change >>>>> for the hotspot_version. I will re-run tests if you wish but it seems >>>>> unnecessary. >>>>> >>>>> Cheers! >>>>> Chris >>>>> >>>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>>>> Hi >>>>>>> >>>>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>>>> sponsor >>>>>>> - Twisti ? } >>>>>>> >>>>>>> Attached is a backport (essentially resurrection of the Permgen >>>>>>> code) >>>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and >>>>>>> built >>>>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>>>> >>>>>>> Please review. >>>>>>> >>>>>>> Cheers! >>>>>>> Chris >>>>>>> PS >>>>>>> Webrev is here: >>>>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ >>>>>>> >>>>>>> >>>>>> Hi >>>>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>>>> Can you rework the patch/webrev against this repo: >>>>>> >>>>>> http://hg.openjdk.java.net/hsx/hsx24/hotspot >>>>>> >>>>>> once it's reviewed I can push it >>>>>> >>>>>> Thanks >>>>>> >>>> > > > From ioi.lam at oracle.com Fri Jan 18 09:40:09 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 18 Jan 2013 09:40:09 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <50F74858.5090502@oracle.com> References: <50F74858.5090502@oracle.com> Message-ID: <50F988F9.8070903@oracle.com> Forwarding to hotspot-dev, since no one replied from hotspot-runtime-dev. Mikael, any comments? Thanks - Ioi -------- Original Message -------- Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics Date: Wed, 16 Jan 2013 16:39:52 -0800 From: Ioi Lam To: hotspot-runtime-dev at openjdk.java.net Please review: http://cr.openjdk.java.net/~acorn/class_stats_010/ Bug: RFE: PrintClassHistogram improvements https://jbs.oracle.com/bugs/browse/JDK-6479360 Sponsor: Karen Kinnear Summary: A new diagnostic command "jcmd GC.class_stats" is added. The user can invoke this command to connect to a live JVM and dump a detailed report of size statistics of all loaded classes (including array classes and anonymous classes). ==========SYNOPSIS=================================== $ jcmd $PID help GC.class_stats Provide statistics about Java class meta data. Impact: High: Depends on Java heap size and content. Syntax : GC.class_stats [options] [] Arguments: columns : [optional] Comma-separated list of all the columns to show. If not specified, the following columns are shown: InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, MethodAll,ROAll,RWAll,Total (STRING, no default value) Options: (options must be specified using the or = syntax) -all : [optional] Show all columns (BOOLEAN, false) -csv : [optional] Print in CSV (comma-separated values) format for spreadsheets (BOOLEAN, false) -help : [optional] Show meaning of all the columns (BOOLEAN, false) ====================================================== By default, the output is human-readable tabulated text format. The user can also select CSV format (comma-separated values) to be used with spreadsheets. A large number of columns are available. By default, a few "summary columns" (e.g., size of Klass objects, total read-only data, etc) are printed. The user can also manually select the columns. Please see the attachments in the bug for sample output, as well as a listing of all the columns and their meanings: https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 Impact: If this diagnostic command is not used, there should be no impact to the JVM's execution, except for + libjvm.so footprint increase (about 10KB larger on Linux/x64) + one additional virtual method in Klass. This feature is excluded when INCLUDE_SERVICES=0 (e.g., embedded builds). Tests run: + JPRT -- (hotspot only) to verify build-ability + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 + I intend to add a new testcase once this is committed: https://jbs.oracle.com/bugs/browse/JDK-8006413 Add utility classes for writing better multiprocess tests in jtreg Thanks, Ioi From alejandro.murillo at oracle.com Fri Jan 18 10:10:08 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 18 Jan 2013 18:10:08 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130118181023.071E2473D0@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a3e54283c54 Merge ! .hgtags Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version From zhengyu.gu at oracle.com Fri Jan 18 10:22:25 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 18 Jan 2013 13:22:25 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code Message-ID: <50F992E1.6050704@oracle.com> Hi, This is a cleanup of kernel code, since it is already obsoleted - JDK7 and JDK8 are no longer building kernel. JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ Tests: - JPRT - ute vm.quick.testlist on Linux x32. Thanks, -Zhengyu From staffan.larsen at oracle.com Fri Jan 18 10:44:11 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 18 Jan 2013 18:44:11 +0000 Subject: hg: hsx/hsx24/hotspot: 8006400: Add support for defining trace types in closed code Message-ID: <20130118184422.18B11473D3@hg.openjdk.java.net> Changeset: 6f113f191e4e Author: ehelin Date: 2013-01-17 16:32 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6f113f191e4e 8006400: Add support for defining trace types in closed code Reviewed-by: sla, nloodin, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/trace/trace.dtd ! src/share/vm/trace/trace.xml From vladimir.kozlov at oracle.com Fri Jan 18 14:00:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jan 2013 14:00:29 -0800 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: <50F97A4D.50606@LGonQn.Org> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> Message-ID: <50F9C5FD.4050706@oracle.com> Looks good. Vladimir On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: > Hi Alejandro, > > Have updated the webrev (just off by one line in 1 file) and built both > normal > hotspot and zero on x86_64 based on the hsx24 repo head: > http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/ > [Also now contains updated copyrights] > > Cheers! > Chris > > On 18/01/13 05:56 AM, Alejandro E Murillo wrote: >> >> Hi Chris (Phillips) >> I just got a snapshot of hs24 and bumped the build number to b31, >> so we can resume pushing bug fixes to it. >> Unfortunately the patch in the webrev at [1] does not apply cleanly >> anymore, >> Can you guys reapply the changes to clean clone of [2] and send the >> new webrev? >> Then if the previous reviewers approve it, I will push that soon >> after so it makes >> it into next week snapshot. Apologies for the extra work >> >> [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ >> >> [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot >> >> >> >> Thanks >> Alejandro >> >> >> On 1/2/2013 1:02 PM, Christian Thalinger wrote: >>> On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T >>> O wrote: >>> >>>> Hi Alejandro, >>>> Oops emails crossed in the net ... >>>> See my latest email , I had to regenerate the webrev and patch - >>>> This webrev s/b ok: >>>> >>>> Webrev: >>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ >>>> >>> That looks good. -- Chris >>> >>>> Chris >>>> >>>> On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >>>>> Hi Chris, >>>>> In that case is not necessary. >>>>> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >>>>> but looks like it is against hsx/hsx24/hotspot. >>>>> BTW, I went to check the webrev link and is unreachable, can you check >>>>> that? >>>>> Thanks >>>>> Alejandro >>>>> >>>>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>>>>> Hi Alejandro, >>>>>> >>>>>> The only change since I tested this afternoon is the change >>>>>> for the hotspot_version. I will re-run tests if you wish but it seems >>>>>> unnecessary. >>>>>> >>>>>> Cheers! >>>>>> Chris >>>>>> >>>>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>>>>> sponsor >>>>>>>> - Twisti ? } >>>>>>>> >>>>>>>> Attached is a backport (essentially resurrection of the Permgen >>>>>>>> code) >>>>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and >>>>>>>> built >>>>>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>>>>> >>>>>>>> Please review. >>>>>>>> >>>>>>>> Cheers! >>>>>>>> Chris >>>>>>>> PS >>>>>>>> Webrev is here: >>>>>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ >>>>>>>> >>>>>>>> >>>>>>> Hi >>>>>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>>>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>>>>> Can you rework the patch/webrev against this repo: >>>>>>> >>>>>>> http://hg.openjdk.java.net/hsx/hsx24/hotspot >>>>>>> >>>>>>> once it's reviewed I can push it >>>>>>> >>>>>>> Thanks >>>>>>> >>>>> >> >> >> > From zhengyu.gu at oracle.com Fri Jan 18 14:06:39 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 18 Jan 2013 17:06:39 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50F9C403.6070700@oracle.com> References: <50F9C403.6070700@oracle.com> Message-ID: <50F9C76F.4080701@oracle.com> Hi Chris, Thanks for reviewing. On 1/18/2013 4:52 PM, Chris Plummer wrote: > make/windows/makefiles/vm.make: You missed the copyright update > Thanks. > src/share/vm/classfile/systemDictionary.cpp: I guess the removal of > the following code is correct. The original code was odd since it had > a kernel reference outside of #ifdef KERNEL, and then a non-kernel > reference (which you removed), within the "if". Just want to double > check that this is the right thing to do. > > 1826 if (init_opt == SystemDictionary::Opt_Kernel) { > 1827 #ifndef KERNEL > 1828 try_load = false; > 1829 #endif //KERNEL > 1830 } I removed SystemDictionary::Opt_Kernel. Can anyone verify if it is OK? > > src/share/vm/prims/jniCheck.hpp: The #ifndef removal is correct, but > not removing what is within the #ifndef. > Thanks, -Zhengyu > Chris > > On 1/18/13 12:00 PM, hotspot-dev-request at openjdk.java.net wrote: >> Hi, >> >> This is a cleanup of kernel code, since it is already obsoleted - JDK7 >> and JDK8 are no longer building kernel. >> >> JBS:https://jbs.oracle.com/bugs/browse/JDK-8000692 >> Webrev:http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ >> >> Tests: >> - JPRT >> - ute vm.quick.testlist on Linux x32. >> >> Thanks, >> >> -Zhengyu > From joseph.provino at oracle.com Fri Jan 18 14:27:06 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 18 Jan 2013 17:27:06 -0500 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Message-ID: <50F9CC3A.7080608@oracle.com> INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. A new webrev is available here: http://cr.openjdk.java.net/~jprovino/8005915/webrev.01/ macros.hpp needed to be included in files which use INCLUDE_XXX. joe From staffan.larsen at oracle.com Fri Jan 18 14:38:57 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 18 Jan 2013 22:38:57 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130118223906.07BE8473DF@hg.openjdk.java.net> Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/617b18aadb33 Merge From coleen.phillimore at oracle.com Fri Jan 18 14:56:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Jan 2013 17:56:45 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50F9C76F.4080701@oracle.com> References: <50F9C403.6070700@oracle.com> <50F9C76F.4080701@oracle.com> Message-ID: <50F9D32D.4080000@oracle.com> Zhengyu, This looks good. Did you verify that it still builds the minimal1 vm and the minimal before/after sizes are the same? Is there a minimal vm on windows? On 1/18/2013 5:06 PM, Zhengyu Gu wrote: > Hi Chris, > > Thanks for reviewing. > > On 1/18/2013 4:52 PM, Chris Plummer wrote: >> make/windows/makefiles/vm.make: You missed the copyright update >> > Thanks. >> src/share/vm/classfile/systemDictionary.cpp: I guess the removal of >> the following code is correct. The original code was odd since it had >> a kernel reference outside of #ifdef KERNEL, and then a non-kernel >> reference (which you removed), within the "if". Just want to double >> check that this is the right thing to do. Yes, this can be removed. It just meant that this class was optional and only supported with the kernel build. Thanks for cleaning this up! Coleen >> >> 1826 if (init_opt == SystemDictionary::Opt_Kernel) { >> 1827 #ifndef KERNEL >> 1828 try_load = false; >> 1829 #endif //KERNEL >> 1830 } > I removed SystemDictionary::Opt_Kernel. Can anyone verify if it is OK? > >> >> src/share/vm/prims/jniCheck.hpp: The #ifndef removal is correct, but >> not removing what is within the #ifndef. >> > Thanks, > > -Zhengyu > >> Chris >> >> On 1/18/13 12:00 PM, hotspot-dev-request at openjdk.java.net wrote: >>> Hi, >>> >>> This is a cleanup of kernel code, since it is already obsoleted - JDK7 >>> and JDK8 are no longer building kernel. >>> >>> JBS:https://jbs.oracle.com/bugs/browse/JDK-8000692 >>> Webrev:http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ >>> >>> Tests: >>> - JPRT >>> - ute vm.quick.testlist on Linux x32. >>> >>> Thanks, >>> >>> -Zhengyu >> From karen.kinnear at oracle.com Fri Jan 18 14:58:54 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 18 Jan 2013 17:58:54 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50F992E1.6050704@oracle.com> References: <50F992E1.6050704@oracle.com> Message-ID: <9135046D-E7BF-4D8F-AA81-3AB156F71BEB@oracle.com> Zhengyu, Thank you for doing this. Looks good. Can you also please remove from vmSymbols - sun/jkernel/Download/Manager and getBootClassPathEntryForClass? And assembler_x86.hpp - perhaps modify the comment from "KERNEL" to MINIMAL VM" SystemDictionary.cpp: initialize_wk_klass - your changes there look good to me, with Opt_Kernel completely gone thanks, Karen On Jan 18, 2013, at 1:22 PM, Zhengyu Gu wrote: > Hi, > > This is a cleanup of kernel code, since it is already obsoleted - JDK7 and JDK8 are no longer building kernel. > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 > Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ > > Tests: > - JPRT > - ute vm.quick.testlist on Linux x32. > > Thanks, > > -Zhengyu From stuart.marks at oracle.com Fri Jan 18 18:25:40 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 18 Jan 2013 18:25:40 -0800 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <50F6B0C7.4040405@oracle.com> <50F7F904.3050004@oracle.com> <9c27ed4e-8189-46e6-8856-3cec5fe158a1@default> <50F811BB.3060803@oracle.com> <50F82824.8070909@oracle.com> <50F82EAE.3020100@oracle.com> <50F83BBF.5000807@oracle.com> <50F84418.6070908@oracle.com> Message-ID: <50FA0424.7040907@oracle.com> Wow, a huge thread here. A few general comments. Shell Tests. While shell scripts seem to make it really easy to manage subprocesses and create pipelines, in practice we've found that they really have caused a lot of problems. Joe mentioned that they seem to contribute more than their proportion of failures during pre-integration testing. I've also run across several instances of "bugs" in shell tests, where they mishandle unexpected conditions or destroy valuable diagnostic information. In the JDK regression suite we have a lot of intermittent failures. To the extent that shell tests contribute more than their share of such failures, we're strongly considering rewriting these tests in Java in order to make them more reliable. And, as already has been stated, we'd like to discourage writing of new shell tests. Process Infrastructure in JTreg. If we're going to be writing tests in Java that manage subprocesses, this will require some support and infrastructure code. Shouldn't this be put into a place like JTreg where everybody can use it? Perhaps conceptually yes. The main problem is that JTreg evolves separately and asynchronously from the platform. If a test needed a new bit of infrastructure, it would have to wait until it was added to JTreg. If the infrastructure library is in the same repo as the tests, they could all be updated simultaneously. A Single Shared Infrastructure Library. If we're to have a library, shouldn't we have a single library that everybody uses? Again, conceptually yes, but there are a couple layers of problems in the way. The first is that hotspot and jdk are different repositories, and trying to have a single one would introduce more dependencies across the repositories, which we all understand is very difficult to manage. Keeping the libraries in synch, using some external process (e.g. a script run regularly) would still be a problem. If a change in, say, the jdk version of the test library would cause a problem in the hotspot tests, that would be a big effort to reconcile. This occurs even if there's a test library that's shared among a bunch of tests in the same repo. That library has to accommodate everybody's requirements, and it can't be changed unless it's assured that it doesn't break anything. Maintaining and evolving such a library will require a significant amount of effort. Creating such a library is a good idea, but we're not there yet. I don't think our test library code is mature enough yet. What I don't want to have happen is for there to be a "test library" that's simply a dumping ground for code that is potentially sharable, that might be useful across a bunch of tests, but which a) nobody actually uses, because they don't want to be exposed to breakage if it's changed, and b) which nobody maintains, because they're afraid of changing something that might break somebody. We're left with the situation of having each area of the code define its own library, like the RMI test library is used only by RMI. This means that some test library code will be duplicated. This is bad, but it's less bad than what I outlined above, and I hope it's only temporary. s'marks From alejandro.murillo at oracle.com Fri Jan 18 20:55:15 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 19 Jan 2013 04:55:15 +0000 Subject: hg: hsx/hsx24/hotspot: 8000780: make Zero build and run with JDK8 Message-ID: <20130119045521.4A2E1473ED@hg.openjdk.java.net> Changeset: 8a60837325f0 Author: amurillo Date: 2013-01-18 16:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8a60837325f0 8000780: make Zero build and run with JDK8 Reviewed-by: twisti, kvn Contributed-by: Chris Phillips ! make/Makefile ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp From christian.tornqvist at oracle.com Sun Jan 20 09:29:41 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Sun, 20 Jan 2013 09:29:41 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F959B9.4070204@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> Message-ID: <8db4dc83-0528-40bd-bac0-6e5032e5be57@default> Hi Vladimir, > stdout & stderr are stored in the same buffer. I don't see why the output can't be interleaved, so consequent analysis could fail intermittently. I > suggest to store and analyze them separately. Also, it'll allow to limit the search to concrete stream. Excellent point, I've changed it so that they're now stored separately and added methods for analyzing them separately too. Thanks, Christian -----Original Message----- From: Vladimir Ivanov Sent: den 18 januari 2013 15:19 To: Christian T?rnqvist Cc: hotspot-dev at openjdk.java.net; Yekaterina Kantserova Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Christian, Nice work! Thanks for adding this. I have a couple of comments. Don't consider me too paranoic, please :-) test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: 60 public static String getOutput(Process process) throws IOException { 61 ByteArrayOutputStream buf = new ByteArrayOutputStream(); 62 StreamPumper outPumper = new StreamPumper(process.getInputStream(), buf); 63 StreamPumper errPumper = new StreamPumper(process.getErrorStream(), buf); stdout & stderr are stored in the same buffer. I don't see why the output can't be interleaved, so consequent analysis could fail intermittently. I suggest to store and analyze them separately. Also, it'll allow to limit the search to concrete stream. In the following code: test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: 54 public void run() { 55 int length; 56 try { 57 byte[] buffer = new byte[BUF_SIZE]; 58 InputStream localIn = in; 59 OutputStream localOut = out; 60 while ((length = localIn.read(buffer)) > 0 && !Thread.interrupted()) { 61 localOut.write(buffer, 0, length); 62 } 63 localOut.flush(); 64 } catch (IOException e) { 65 // Just abort if something like this happens. 66 e.printStackTrace(); 67 } 68 } Thread.interrupted call is redundant: if the thread is interrupted, exception will be thrown from localIn.read call anyway. Also, I would suggest to move localOut.flush to finally clause, since the call can be skipped in case of thread interruption. Best regards, Vladimir Ivanov On 1/18/13 3:43 PM, Christian T?rnqvist wrote: > Another updated webrev at http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , formatting changes. > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 17:44 > To: hotspot-dev at openjdk.java.net > Cc: Vitaly Davidovich; Yekaterina Kantserova > Subject: RE: RFR (S): 8006413: Add utility classes for writing better > multiprocess tests in jtreg > > Updated webrev can be found at > http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots > of small changes based on all the great feedback I got :) > > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 17 januari 2013 15:19 > To: Vitaly Davidovich > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better > multiprocess tests in jtreg > > Hi Vitaly, > > First of all, thanks for all your feedback :) > >> - not entirely sure what getPlatformSpecificVMArgs is really meant >> for. Maybe just have an is64bitJVM() instead? You can just return >> "new String[0]" though (I'm not a fan of extra >braces) > > This is for dealing with platform specific arguments to the java launcher (more importantly, not having the test worry about these things). Right now we only have the requirement to send '-d64' to any process launched as 64bit on Solaris, in the future we might have other requirements. That's the reason for giving this a more general name. > >> - there's no non-reflective way to get the pid? > > Not that I've found :( > > > > I've taken a lot of your comments and made changes to the classes, I'll be publishing an updated webrev soon. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: den 16 januari 2013 16:30 > To: Christian T?rnqvist > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR (S): 8006413: Add utility classes for writing better > multiprocess tests in jtreg > > > > Some of this is style so feel free to ignore: > > I'd mark all these classes final for now. I'd also hide the default ctor for the util classes that only have static methods. > > JDKToolFinder > - Check that the jdk.test sysprop is not empty as well. > > - Remove the throws clause from the method - don't think it adds any value. > > - RuntimeException seems more idiomatic instead of Exception > > - after creating the full path string, might be nice to verify that it exists and throw if not (things will not work later but you can provide a better error message here). Perhaps even return a File or Path instance instead of string. > > OutputAnalyzer > - any reason fields are default visible? Make them private and final. > > - should probably check that output is not null in the constructors > > - it's possible to chain the constructors here > > - same comment about throws clauses on methods + RuntimeException as > above > > ProcessTools > - getOutput swallows IOException and returns "". Not sure this is best - I think the test should fail as you can't trust the results at this point. > > - StreamPumper extends Thread so I don't think you need the wrapper threads here. Cleaner is to make StreamPumper implement Runnable though and use threads here. > > - interruption is caught and restored but no guarantee caller will observe it now. Again, don't think returning "" is right as results are indeterminate. I'd let the interrupt bubble up. > > - there's no non-reflective way to get the pid? > > - not entirely sure what getPlatformSpecificVMArgs is really meant > for. Maybe just have an is64bitJVM() instead? You can just return > "new String[0]" though (I'm not a fan of extra braces) > > -createJavaProcessBuilder() can probably just use List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. > > StreamPumper > - check ctor args for null reference. The fields can be final as well. > > That's all for now :). > > Thanks > Sent from my phone > > On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" wrote: > > Hi Vitaly, > > > > Setting them as daemon sounds like a good idea :) > > > > I'd like your feedback on the other things as well, the quality of test code is important. > > > > Thanks, > > Christian > > > > From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" > \nvitalyd at gmail.com] > Sent: den 16 januari 2013 14:50 > To: Christian T?rnqvist > Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" > \nhotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8006413: Add utility classes for writing better > multiprocess tests in jtreg > > > > Hi Christian, > > Not sure how polished you want/need this code to be since it's just utility, but one thing that jumped out was the stream pumper threads for reading stdout/err should be daemonized just to play it safe. > > There are some other things that can be done, but not sure it's worth the effort for a testing utility. Let me know though if you'd like to cover everything. > > Thanks > > Sent from my phone > > On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" wrote: > > Hi everyone, > > > > This RFE adds a few utility classes to make it a bit easier to write > multi-process tests in jtreg, webrev can be found at > http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ > > > > Thanks, > > Christian > From christian.tornqvist at oracle.com Sun Jan 20 09:32:02 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Sun, 20 Jan 2013 09:32:02 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F95ADB.3010304@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> <50F95ADB.3010304@oracle.com> Message-ID: <6958d057-b9ac-418c-88ed-fd895e0dd85f@default> > One more comment: I don't see where you close streams acquired from Process.getOutputStream()/Process.getErrorStream(). Is it overlooked? Fixed, they're now closed in the finally block in StreamPumper Thanks, Christian -----Original Message----- From: Vladimir Ivanov Sent: den 18 januari 2013 15:23 To: Christian T?rnqvist Cc: hotspot-dev at openjdk.java.net; Yekaterina Kantserova Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg Hit "Send" too early... One more comment: I don't see where you close streams acquired from Process.getOutputStream()/Process.getErrorStream(). Is it overlooked? Best regards, Vladimir Ivanov On 1/18/13 5:18 PM, Vladimir Ivanov wrote: > Christian, > > Nice work! Thanks for adding this. > > I have a couple of comments. Don't consider me too paranoic, please > :-) > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: > 60 public static String getOutput(Process process) throws > IOException { > 61 ByteArrayOutputStream buf = new ByteArrayOutputStream(); > 62 StreamPumper outPumper = new > StreamPumper(process.getInputStream(), buf); > 63 StreamPumper errPumper = new > StreamPumper(process.getErrorStream(), buf); > > stdout & stderr are stored in the same buffer. I don't see why the > output can't be interleaved, so consequent analysis could fail > intermittently. I suggest to store and analyze them separately. Also, > it'll allow to limit the search to concrete stream. > > In the following code: > test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: > 54 public void run() { > 55 int length; > 56 try { > 57 byte[] buffer = new byte[BUF_SIZE]; > 58 InputStream localIn = in; > 59 OutputStream localOut = out; > 60 while ((length = localIn.read(buffer)) > 0 && > !Thread.interrupted()) { > 61 localOut.write(buffer, 0, length); > 62 } > 63 localOut.flush(); > 64 } catch (IOException e) { > 65 // Just abort if something like this happens. > 66 e.printStackTrace(); > 67 } > 68 } > > Thread.interrupted call is redundant: if the thread is interrupted, > exception will be thrown from localIn.read call anyway. > > Also, I would suggest to move localOut.flush to finally clause, since > the call can be skipped in case of thread interruption. > > Best regards, > Vladimir Ivanov > > On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >> Another updated webrev at >> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >> formatting changes. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 17:44 >> To: hotspot-dev at openjdk.java.net >> Cc: Vitaly Davidovich; Yekaterina Kantserova >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Updated webrev can be found at >> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . >> Lots of small changes based on all the great feedback I got :) >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 15:19 >> To: Vitaly Davidovich >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Hi Vitaly, >> >> First of all, thanks for all your feedback :) >> >>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>> for. Maybe just have an is64bitJVM() instead? You can just return >>> "new String[0]" though (I'm not a fan of extra >braces) >> >> This is for dealing with platform specific arguments to the java >> launcher (more importantly, not having the test worry about these >> things). Right now we only have the requirement to send '-d64' to any >> process launched as 64bit on Solaris, in the future we might have >> other requirements. That's the reason for giving this a more general >> name. >> >>> - there's no non-reflective way to get the pid? >> >> Not that I've found :( >> >> >> >> I've taken a lot of your comments and made changes to the classes, >> I'll be publishing an updated webrev soon. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: den 16 januari 2013 16:30 >> To: Christian T?rnqvist >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Some of this is style so feel free to ignore: >> >> I'd mark all these classes final for now. I'd also hide the default >> ctor for the util classes that only have static methods. >> >> JDKToolFinder >> - Check that the jdk.test sysprop is not empty as well. >> >> - Remove the throws clause from the method - don't think it adds any >> value. >> >> - RuntimeException seems more idiomatic instead of Exception >> >> - after creating the full path string, might be nice to verify that >> it exists and throw if not (things will not work later but you can >> provide a better error message here). Perhaps even return a File or >> Path instance instead of string. >> >> OutputAnalyzer >> - any reason fields are default visible? Make them private and final. >> >> - should probably check that output is not null in the constructors >> >> - it's possible to chain the constructors here >> >> - same comment about throws clauses on methods + RuntimeException as >> above >> >> ProcessTools >> - getOutput swallows IOException and returns "". Not sure this is >> best - I think the test should fail as you can't trust the results at >> this point. >> >> - StreamPumper extends Thread so I don't think you need the wrapper >> threads here. Cleaner is to make StreamPumper implement Runnable >> though and use threads here. >> >> - interruption is caught and restored but no guarantee caller will >> observe it now. Again, don't think returning "" is right as results >> are indeterminate. I'd let the interrupt bubble up. >> >> - there's no non-reflective way to get the pid? >> >> - not entirely sure what getPlatformSpecificVMArgs is really meant >> for. Maybe just have an is64bitJVM() instead? You can just return >> "new String[0]" though (I'm not a fan of extra braces) >> >> -createJavaProcessBuilder() can probably just use >> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >> >> StreamPumper >> - check ctor args for null reference. The fields can be final as well. >> >> That's all for now :). >> >> Thanks >> Sent from my phone >> >> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.com >> > >> wrote: >> >> Hi Vitaly, >> >> >> >> Setting them as daemon sounds like a good idea :) >> >> >> >> I'd like your feedback on the other things as well, the quality of >> test code is important. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >> \nvitalyd at gmail.com] >> Sent: den 16 januari 2013 14:50 >> To: Christian T?rnqvist >> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >> \nhotspot-dev at openjdk.java.net >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Hi Christian, >> >> Not sure how polished you want/need this code to be since it's just >> utility, but one thing that jumped out was the stream pumper threads >> for reading stdout/err should be daemonized just to play it safe. >> >> There are some other things that can be done, but not sure it's worth >> the effort for a testing utility. Let me know though if you'd like >> to cover everything. >> >> Thanks >> >> Sent from my phone >> >> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com" >> \nchristian.tornqvist at oracle.com> wrote: >> >> Hi everyone, >> >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> >> >> Thanks, >> >> Christian >> From david.holmes at oracle.com Sun Jan 20 17:36:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 11:36:49 +1000 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50F9C76F.4080701@oracle.com> References: <50F9C403.6070700@oracle.com> <50F9C76F.4080701@oracle.com> Message-ID: <50FC9BB1.7060000@oracle.com> On 19/01/2013 8:06 AM, Zhengyu Gu wrote: > On 1/18/2013 4:52 PM, Chris Plummer wrote: >> src/share/vm/classfile/systemDictionary.cpp: I guess the removal of >> the following code is correct. The original code was odd since it had >> a kernel reference outside of #ifdef KERNEL, and then a non-kernel >> reference (which you removed), within the "if". Just want to double >> check that this is the right thing to do. >> >> 1826 if (init_opt == SystemDictionary::Opt_Kernel) { >> 1827 #ifndef KERNEL >> 1828 try_load = false; >> 1829 #endif //KERNEL >> 1830 } > I removed SystemDictionary::Opt_Kernel. Can anyone verify if it is OK? Yes. Also note that the try_load flag is now always true and so can be removed. David From david.holmes at oracle.com Sun Jan 20 17:54:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 11:54:21 +1000 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50F992E1.6050704@oracle.com> References: <50F992E1.6050704@oracle.com> Message-ID: <50FC9FCD.2010806@oracle.com> Hi Zhengyu, In addition to comments already made: src/share/vm/prims/jvm.cpp info->is_kernel_jvm = 0; // false; Does this imply we need to update the spec and definition of jvm_version_info? And are there further changes needed on the JDK side? Where is/was the jkernel download manager class? Thanks, David On 19/01/2013 4:22 AM, Zhengyu Gu wrote: > Hi, > > This is a cleanup of kernel code, since it is already obsoleted - JDK7 > and JDK8 are no longer building kernel. > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 > Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ > > Tests: > - JPRT > - ute vm.quick.testlist on Linux x32. > > Thanks, > > -Zhengyu From david.holmes at oracle.com Sun Jan 20 18:13:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 12:13:01 +1000 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50F959B9.4070204@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> Message-ID: <50FCA42D.8070307@oracle.com> On 19/01/2013 12:18 AM, Vladimir Ivanov wrote: > Christian, > > Nice work! Thanks for adding this. > > I have a couple of comments. Don't consider me too paranoic, please :-) > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: > 60 public static String getOutput(Process process) throws IOException { > 61 ByteArrayOutputStream buf = new ByteArrayOutputStream(); > 62 StreamPumper outPumper = new StreamPumper(process.getInputStream(), > buf); > 63 StreamPumper errPumper = new StreamPumper(process.getErrorStream(), > buf); > > stdout & stderr are stored in the same buffer. I don't see why the > output can't be interleaved, so consequent analysis could fail > intermittently. I suggest to store and analyze them separately. Also, > it'll allow to limit the search to concrete stream. So one problem here, regardless of whether you use one buf or two is that there seems to be no way to correlate the output and error streams, unless they were already going to the same sink - in which case you would want them both to go to buf anyway. > In the following code: > test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: > 54 public void run() { > 55 int length; > 56 try { > 57 byte[] buffer = new byte[BUF_SIZE]; > 58 InputStream localIn = in; > 59 OutputStream localOut = out; > 60 while ((length = localIn.read(buffer)) > 0 && !Thread.interrupted()) { > 61 localOut.write(buffer, 0, length); > 62 } > 63 localOut.flush(); > 64 } catch (IOException e) { > 65 // Just abort if something like this happens. > 66 e.printStackTrace(); > 67 } > 68 } > > Thread.interrupted call is redundant: if the thread is interrupted, > exception will be thrown from localIn.read call anyway. That is dependent on the underlying stream implementation and whether interruptible I/O is supported (which it no longer is [and only ever was on Solaris]). David ----- > Also, I would suggest to move localOut.flush to finally clause, since > the call can be skipped in case of thread interruption. > > Best regards, > Vladimir Ivanov > > On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >> Another updated webrev at >> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >> formatting changes. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 17:44 >> To: hotspot-dev at openjdk.java.net >> Cc: Vitaly Davidovich; Yekaterina Kantserova >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Updated webrev can be found at >> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots >> of small changes based on all the great feedback I got :) >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 15:19 >> To: Vitaly Davidovich >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Hi Vitaly, >> >> First of all, thanks for all your feedback :) >> >>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>> for. Maybe just have an is64bitJVM() instead? You can just return >>> "new String[0]" though (I'm not a fan of extra >braces) >> >> This is for dealing with platform specific arguments to the java >> launcher (more importantly, not having the test worry about these >> things). Right now we only have the requirement to send '-d64' to any >> process launched as 64bit on Solaris, in the future we might have >> other requirements. That's the reason for giving this a more general >> name. >> >>> - there's no non-reflective way to get the pid? >> >> Not that I've found :( >> >> >> >> I've taken a lot of your comments and made changes to the classes, >> I'll be publishing an updated webrev soon. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: den 16 januari 2013 16:30 >> To: Christian T?rnqvist >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Some of this is style so feel free to ignore: >> >> I'd mark all these classes final for now. I'd also hide the default >> ctor for the util classes that only have static methods. >> >> JDKToolFinder >> - Check that the jdk.test sysprop is not empty as well. >> >> - Remove the throws clause from the method - don't think it adds any >> value. >> >> - RuntimeException seems more idiomatic instead of Exception >> >> - after creating the full path string, might be nice to verify that it >> exists and throw if not (things will not work later but you can >> provide a better error message here). Perhaps even return a File or >> Path instance instead of string. >> >> OutputAnalyzer >> - any reason fields are default visible? Make them private and final. >> >> - should probably check that output is not null in the constructors >> >> - it's possible to chain the constructors here >> >> - same comment about throws clauses on methods + RuntimeException as >> above >> >> ProcessTools >> - getOutput swallows IOException and returns "". Not sure this is best >> - I think the test should fail as you can't trust the results at this >> point. >> >> - StreamPumper extends Thread so I don't think you need the wrapper >> threads here. Cleaner is to make StreamPumper implement Runnable >> though and use threads here. >> >> - interruption is caught and restored but no guarantee caller will >> observe it now. Again, don't think returning "" is right as results >> are indeterminate. I'd let the interrupt bubble up. >> >> - there's no non-reflective way to get the pid? >> >> - not entirely sure what getPlatformSpecificVMArgs is really meant >> for. Maybe just have an is64bitJVM() instead? You can just return "new >> String[0]" though (I'm not a fan of extra braces) >> >> -createJavaProcessBuilder() can probably just use >> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >> >> StreamPumper >> - check ctor args for null reference. The fields can be final as well. >> >> That's all for now :). >> >> Thanks >> Sent from my phone >> >> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.com> >> wrote: >> >> Hi Vitaly, >> >> >> >> Setting them as daemon sounds like a good idea :) >> >> >> >> I'd like your feedback on the other things as well, the quality of >> test code is important. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >> \nvitalyd at gmail.com] >> Sent: den 16 januari 2013 14:50 >> To: Christian T?rnqvist >> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >> \nhotspot-dev at openjdk.java.net >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Hi Christian, >> >> Not sure how polished you want/need this code to be since it's just >> utility, but one thing that jumped out was the stream pumper threads >> for reading stdout/err should be daemonized just to play it safe. >> >> There are some other things that can be done, but not sure it's worth >> the effort for a testing utility. Let me know though if you'd like to >> cover everything. >> >> Thanks >> >> Sent from my phone >> >> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com" >> \nchristian.tornqvist at oracle.com> wrote: >> >> Hi everyone, >> >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> >> >> Thanks, >> >> Christian >> From alejandro.murillo at oracle.com Mon Jan 21 02:15:05 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 21 Jan 2013 03:15:05 -0700 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: <50F9C5FD.4050706@oracle.com> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> Message-ID: <50FD1529.7010303@oracle.com> Thanks Vladimir, I pushed this on Friday, will be in 7u/7u/hotspot next time we take a snapshot of hs24 cheers Alejandro On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: >> Hi Alejandro, >> >> Have updated the webrev (just off by one line in 1 file) and built both >> normal >> hotspot and zero on x86_64 based on the hsx24 repo head: >> http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/ >> [Also now contains updated copyrights] >> >> Cheers! >> Chris >> >> On 18/01/13 05:56 AM, Alejandro E Murillo wrote: >>> >>> Hi Chris (Phillips) >>> I just got a snapshot of hs24 and bumped the build number to b31, >>> so we can resume pushing bug fixes to it. >>> Unfortunately the patch in the webrev at [1] does not apply cleanly >>> anymore, >>> Can you guys reapply the changes to clean clone of [2] and send the >>> new webrev? >>> Then if the previous reviewers approve it, I will push that soon >>> after so it makes >>> it into next week snapshot. Apologies for the extra work >>> >>> [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ >>> >>> >>> [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot >>> >>> >>> >>> Thanks >>> Alejandro >>> >>> >>> On 1/2/2013 1:02 PM, Christian Thalinger wrote: >>>> On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T >>>> O wrote: >>>> >>>>> Hi Alejandro, >>>>> Oops emails crossed in the net ... >>>>> See my latest email , I had to regenerate the webrev and patch - >>>>> This webrev s/b ok: >>>>> >>>>> Webrev: >>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ >>>>> >>>>> >>>> That looks good. -- Chris >>>> >>>>> Chris >>>>> >>>>> On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >>>>>> Hi Chris, >>>>>> In that case is not necessary. >>>>>> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >>>>>> but looks like it is against hsx/hsx24/hotspot. >>>>>> BTW, I went to check the webrev link and is unreachable, can you >>>>>> check >>>>>> that? >>>>>> Thanks >>>>>> Alejandro >>>>>> >>>>>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>>>>>> Hi Alejandro, >>>>>>> >>>>>>> The only change since I tested this afternoon is the change >>>>>>> for the hotspot_version. I will re-run tests if you wish but it >>>>>>> seems >>>>>>> unnecessary. >>>>>>> >>>>>>> Cheers! >>>>>>> Chris >>>>>>> >>>>>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>>>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>>>>>> sponsor >>>>>>>>> - Twisti ? } >>>>>>>>> >>>>>>>>> Attached is a backport (essentially resurrection of the Permgen >>>>>>>>> code) >>>>>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and >>>>>>>>> built >>>>>>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>>>>>> >>>>>>>>> Please review. >>>>>>>>> >>>>>>>>> Cheers! >>>>>>>>> Chris >>>>>>>>> PS >>>>>>>>> Webrev is here: >>>>>>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hi >>>>>>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>>>>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>>>>>> Can you rework the patch/webrev against this repo: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/hsx/hsx24/hotspot >>>>>>>> >>>>>>>> once it's reviewed I can push it >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>> >>> >>> >>> From mikael.gerdin at oracle.com Mon Jan 21 03:34:09 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 21 Jan 2013 12:34:09 +0100 Subject: Review request: JDK-8004147 test/Makefile jtreg_tests target does not work with cygwin Message-ID: <50FD27B1.7000908@oracle.com> Hi, When trying to run the hotspot regression tests with cygwin I noticed that the paths passed to the jtreg launcher suffers from the same issue as was found in JDK-7152791. My suggested fix is to convert the paths before passing them to the jtreg launcher. Webrev: http://cr.openjdk.java.net/~mgerdin/8004147/webrev.0/ -- Mikael Gerdin Java SE VM SQE Stockholm From bengt.rutisson at oracle.com Mon Jan 21 03:48:23 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 21 Jan 2013 12:48:23 +0100 Subject: CFV: New HSX Committer: Erik Helin Message-ID: <50FD2B07.7030802@oracle.com> I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX Committer. Erik is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com Votes are due by February 4, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Bengt [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From krystal.mo at oracle.com Mon Jan 21 03:51:40 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Mon, 21 Jan 2013 19:51:40 +0800 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <50FD2BCC.3020009@oracle.com> Vote: yes Cheers, Kris On 01/21/2013 07:48 PM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From christian.tornqvist at oracle.com Mon Jan 21 03:58:22 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 21 Jan 2013 03:58:22 -0800 (PST) Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <2d7f6a65-0e26-4249-aa3b-ae6c063f2ded@default> Vote: yes -----Original Message----- From: Bengt Rutisson Sent: den 21 januari 2013 12:48 To: hotspot-dev at openjdk.java.net Subject: CFV: New HSX Committer: Erik Helin I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX Committer. Erik is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com Votes are due by February 4, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Bengt [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From bengt.rutisson at oracle.com Mon Jan 21 04:00:11 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 21 Jan 2013 13:00:11 +0100 Subject: Review request: JDK-8004147 test/Makefile jtreg_tests target does not work with cygwin In-Reply-To: <50FD27B1.7000908@oracle.com> References: <50FD27B1.7000908@oracle.com> Message-ID: <50FD2DCB.90907@oracle.com> Mikael, Looks good. Thanks for fixing this! Bengt On 1/21/13 12:34 PM, Mikael Gerdin wrote: > Hi, > > When trying to run the hotspot regression tests with cygwin I noticed > that the paths passed to the jtreg launcher suffers from the same > issue as was found in JDK-7152791. > > My suggested fix is to convert the paths before passing them to the > jtreg launcher. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8004147/webrev.0/ > > > From ChrisPhi at LGonQn.Org Mon Jan 21 04:00:18 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Mon, 21 Jan 2013 07:00:18 -0500 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated][resend] In-Reply-To: <50FD1529.7010303@oracle.com> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> <50FD1529.7010303@oracle.com> Message-ID: <50FD2DD2.4030109@LGonQn.Org> Hi On 21/01/13 05:15 AM, Alejandro E Murillo wrote: > > Thanks Vladimir, > I pushed this on Friday, will be in 7u/7u/hotspot next time we take a > snapshot of hs24 > cheers > Alejandro Thanks Alejandro, Vladimir, Christian and Roman! Cheers! Chris From stefan.karlsson at oracle.com Mon Jan 21 04:08:02 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 21 Jan 2013 13:08:02 +0100 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <50FD2FA2.9000906@oracle.com> vote: yes StefanK On 01/21/2013 12:48 PM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From staffan.larsen at oracle.com Mon Jan 21 04:15:06 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Jan 2013 13:15:06 +0100 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <6D18AB93-94E3-48FE-BC39-8AD020DCA357@oracle.com> Vote: yes On 21 jan 2013, at 12:48, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From jesper.wilhelmsson at oracle.com Mon Jan 21 05:04:46 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 21 Jan 2013 14:04:46 +0100 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <50FD3CEE.4080705@oracle.com> Vote: yes /Jesper On 21/1/13 12:48 PM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From christian.tornqvist at oracle.com Mon Jan 21 06:56:37 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 21 Jan 2013 06:56:37 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50FCA42D.8070307@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> <50FCA42D.8070307@oracle.com> Message-ID: <8d3f79e9-f6d3-4b82-adeb-e9b3f9cfabb6@default> New webrev up at http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ , the changes from .02 are: * Split stdout and stderr into their own buffers * Added methods to OutputAnalyzer to analyze stdout/stderr separately (old method still looks at both of them) * Closing the stdout/stderr streams in StreamPumper once we're done with them * Added a OutputAnalyzerTest to test the OutputAnalyzer class Kept the interrupted check based on David's comment. Thanks, Christian -----Original Message----- From: David Holmes Sent: den 21 januari 2013 03:13 To: Vladimir Ivanov Cc: Christian T?rnqvist; Yekaterina Kantserova; hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg On 19/01/2013 12:18 AM, Vladimir Ivanov wrote: > Christian, > > Nice work! Thanks for adding this. > > I have a couple of comments. Don't consider me too paranoic, please > :-) > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: > 60 public static String getOutput(Process process) throws IOException > { > 61 ByteArrayOutputStream buf = new ByteArrayOutputStream(); > 62 StreamPumper outPumper = new StreamPumper(process.getInputStream(), > buf); > 63 StreamPumper errPumper = new StreamPumper(process.getErrorStream(), > buf); > > stdout & stderr are stored in the same buffer. I don't see why the > output can't be interleaved, so consequent analysis could fail > intermittently. I suggest to store and analyze them separately. Also, > it'll allow to limit the search to concrete stream. So one problem here, regardless of whether you use one buf or two is that there seems to be no way to correlate the output and error streams, unless they were already going to the same sink - in which case you would want them both to go to buf anyway. > In the following code: > test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: > 54 public void run() { > 55 int length; > 56 try { > 57 byte[] buffer = new byte[BUF_SIZE]; > 58 InputStream localIn = in; > 59 OutputStream localOut = out; > 60 while ((length = localIn.read(buffer)) > 0 && > !Thread.interrupted()) { > 61 localOut.write(buffer, 0, length); > 62 } > 63 localOut.flush(); > 64 } catch (IOException e) { > 65 // Just abort if something like this happens. > 66 e.printStackTrace(); > 67 } > 68 } > > Thread.interrupted call is redundant: if the thread is interrupted, > exception will be thrown from localIn.read call anyway. That is dependent on the underlying stream implementation and whether interruptible I/O is supported (which it no longer is [and only ever was on Solaris]). David ----- > Also, I would suggest to move localOut.flush to finally clause, since > the call can be skipped in case of thread interruption. > > Best regards, > Vladimir Ivanov > > On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >> Another updated webrev at >> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >> formatting changes. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 17:44 >> To: hotspot-dev at openjdk.java.net >> Cc: Vitaly Davidovich; Yekaterina Kantserova >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Updated webrev can be found at >> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . >> Lots of small changes based on all the great feedback I got :) >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Christian T?rnqvist >> Sent: den 17 januari 2013 15:19 >> To: Vitaly Davidovich >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> Hi Vitaly, >> >> First of all, thanks for all your feedback :) >> >>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>> for. Maybe just have an is64bitJVM() instead? You can just return >>> "new String[0]" though (I'm not a fan of extra >braces) >> >> This is for dealing with platform specific arguments to the java >> launcher (more importantly, not having the test worry about these >> things). Right now we only have the requirement to send '-d64' to any >> process launched as 64bit on Solaris, in the future we might have >> other requirements. That's the reason for giving this a more general >> name. >> >>> - there's no non-reflective way to get the pid? >> >> Not that I've found :( >> >> >> >> I've taken a lot of your comments and made changes to the classes, >> I'll be publishing an updated webrev soon. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: den 16 januari 2013 16:30 >> To: Christian T?rnqvist >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Some of this is style so feel free to ignore: >> >> I'd mark all these classes final for now. I'd also hide the default >> ctor for the util classes that only have static methods. >> >> JDKToolFinder >> - Check that the jdk.test sysprop is not empty as well. >> >> - Remove the throws clause from the method - don't think it adds any >> value. >> >> - RuntimeException seems more idiomatic instead of Exception >> >> - after creating the full path string, might be nice to verify that >> it exists and throw if not (things will not work later but you can >> provide a better error message here). Perhaps even return a File or >> Path instance instead of string. >> >> OutputAnalyzer >> - any reason fields are default visible? Make them private and final. >> >> - should probably check that output is not null in the constructors >> >> - it's possible to chain the constructors here >> >> - same comment about throws clauses on methods + RuntimeException as >> above >> >> ProcessTools >> - getOutput swallows IOException and returns "". Not sure this is >> best >> - I think the test should fail as you can't trust the results at this >> point. >> >> - StreamPumper extends Thread so I don't think you need the wrapper >> threads here. Cleaner is to make StreamPumper implement Runnable >> though and use threads here. >> >> - interruption is caught and restored but no guarantee caller will >> observe it now. Again, don't think returning "" is right as results >> are indeterminate. I'd let the interrupt bubble up. >> >> - there's no non-reflective way to get the pid? >> >> - not entirely sure what getPlatformSpecificVMArgs is really meant >> for. Maybe just have an is64bitJVM() instead? You can just return >> "new String[0]" though (I'm not a fan of extra braces) >> >> -createJavaProcessBuilder() can probably just use >> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >> >> StreamPumper >> - check ctor args for null reference. The fields can be final as well. >> >> That's all for now :). >> >> Thanks >> Sent from my phone >> >> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.com >> > >> wrote: >> >> Hi Vitaly, >> >> >> >> Setting them as daemon sounds like a good idea :) >> >> >> >> I'd like your feedback on the other things as well, the quality of >> test code is important. >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >> \nvitalyd at gmail.com] >> Sent: den 16 januari 2013 14:50 >> To: Christian T?rnqvist >> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >> \nhotspot-dev at openjdk.java.net >> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> >> >> >> Hi Christian, >> >> Not sure how polished you want/need this code to be since it's just >> utility, but one thing that jumped out was the stream pumper threads >> for reading stdout/err should be daemonized just to play it safe. >> >> There are some other things that can be done, but not sure it's worth >> the effort for a testing utility. Let me know though if you'd like to >> cover everything. >> >> Thanks >> >> Sent from my phone >> >> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" > "mailto:christian.tornqvist at oracle.com" >> \nchristian.tornqvist at oracle.com> wrote: >> >> Hi everyone, >> >> >> >> This RFE adds a few utility classes to make it a bit easier to write >> multi-process tests in jtreg, webrev can be found at >> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >> >> >> >> Thanks, >> >> Christian >> From bengt.rutisson at oracle.com Mon Jan 21 06:56:14 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 21 Jan 2013 14:56:14 +0000 Subject: hg: hsx/hsx24/hotspot: 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Message-ID: <20130121145618.9DB9A47423@hg.openjdk.java.net> Changeset: 553ac1e00352 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/553ac1e00352 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp From vladimir.x.ivanov at oracle.com Mon Jan 21 10:59:35 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 21 Jan 2013 21:59:35 +0300 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50FCA42D.8070307@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> <50FCA42D.8070307@oracle.com> Message-ID: <50FD9017.1070406@oracle.com> >> stdout & stderr are stored in the same buffer. I don't see why the >> output can't be interleaved, so consequent analysis could fail >> intermittently. I suggest to store and analyze them separately. Also, >> it'll allow to limit the search to concrete stream. > > So one problem here, regardless of whether you use one buf or two is > that there seems to be no way to correlate the output and error streams, > unless they were already going to the same sink - in which case you > would want them both to go to buf anyway. I don't think that correlating streams' content is a requirement for proposed solution. Otherwise, more complex approach should be used here. >> Thread.interrupted call is redundant: if the thread is interrupted, >> exception will be thrown from localIn.read call anyway. > > That is dependent on the underlying stream implementation and whether > interruptible I/O is supported (which it no longer is [and only ever was > on Solaris]). Thanks, I wasn't aware about that. Shouldn't the interruption status check be reordered with read then? >> 60 while (!Thread.interrupted() && (length = localIn.read(buffer)) > 0) { Best regards, Vladimir Ivanov >> In the following code: >> test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: >> 54 public void run() { >> 55 int length; >> 56 try { >> 57 byte[] buffer = new byte[BUF_SIZE]; >> 58 InputStream localIn = in; >> 59 OutputStream localOut = out; >> 60 while ((length = localIn.read(buffer)) > 0 && !Thread.interrupted()) { >> 61 localOut.write(buffer, 0, length); >> 62 } >> 63 localOut.flush(); >> 64 } catch (IOException e) { >> 65 // Just abort if something like this happens. >> 66 e.printStackTrace(); >> 67 } >> 68 } >> > > David > ----- > >> Also, I would suggest to move localOut.flush to finally clause, since >> the call can be skipped in case of thread interruption. >> >> Best regards, >> Vladimir Ivanov >> >> On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >>> Another updated webrev at >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >>> formatting changes. >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Christian T?rnqvist >>> Sent: den 17 januari 2013 17:44 >>> To: hotspot-dev at openjdk.java.net >>> Cc: Vitaly Davidovich; Yekaterina Kantserova >>> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> Updated webrev can be found at >>> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots >>> of small changes based on all the great feedback I got :) >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Christian T?rnqvist >>> Sent: den 17 januari 2013 15:19 >>> To: Vitaly Davidovich >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> Hi Vitaly, >>> >>> First of all, thanks for all your feedback :) >>> >>>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>>> for. Maybe just have an is64bitJVM() instead? You can just return >>>> "new String[0]" though (I'm not a fan of extra >braces) >>> >>> This is for dealing with platform specific arguments to the java >>> launcher (more importantly, not having the test worry about these >>> things). Right now we only have the requirement to send '-d64' to any >>> process launched as 64bit on Solaris, in the future we might have >>> other requirements. That's the reason for giving this a more general >>> name. >>> >>>> - there's no non-reflective way to get the pid? >>> >>> Not that I've found :( >>> >>> >>> >>> I've taken a lot of your comments and made changes to the classes, >>> I'll be publishing an updated webrev soon. >>> >>> >>> >>> Thanks, >>> >>> Christian >>> >>> >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: den 16 januari 2013 16:30 >>> To: Christian T?rnqvist >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> >>> >>> Some of this is style so feel free to ignore: >>> >>> I'd mark all these classes final for now. I'd also hide the default >>> ctor for the util classes that only have static methods. >>> >>> JDKToolFinder >>> - Check that the jdk.test sysprop is not empty as well. >>> >>> - Remove the throws clause from the method - don't think it adds any >>> value. >>> >>> - RuntimeException seems more idiomatic instead of Exception >>> >>> - after creating the full path string, might be nice to verify that it >>> exists and throw if not (things will not work later but you can >>> provide a better error message here). Perhaps even return a File or >>> Path instance instead of string. >>> >>> OutputAnalyzer >>> - any reason fields are default visible? Make them private and final. >>> >>> - should probably check that output is not null in the constructors >>> >>> - it's possible to chain the constructors here >>> >>> - same comment about throws clauses on methods + RuntimeException as >>> above >>> >>> ProcessTools >>> - getOutput swallows IOException and returns "". Not sure this is best >>> - I think the test should fail as you can't trust the results at this >>> point. >>> >>> - StreamPumper extends Thread so I don't think you need the wrapper >>> threads here. Cleaner is to make StreamPumper implement Runnable >>> though and use threads here. >>> >>> - interruption is caught and restored but no guarantee caller will >>> observe it now. Again, don't think returning "" is right as results >>> are indeterminate. I'd let the interrupt bubble up. >>> >>> - there's no non-reflective way to get the pid? >>> >>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>> for. Maybe just have an is64bitJVM() instead? You can just return "new >>> String[0]" though (I'm not a fan of extra braces) >>> >>> -createJavaProcessBuilder() can probably just use >>> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >>> >>> StreamPumper >>> - check ctor args for null reference. The fields can be final as well. >>> >>> That's all for now :). >>> >>> Thanks >>> Sent from my phone >>> >>> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" >> "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.com> >>> wrote: >>> >>> Hi Vitaly, >>> >>> >>> >>> Setting them as daemon sounds like a good idea :) >>> >>> >>> >>> I'd like your feedback on the other things as well, the quality of >>> test code is important. >>> >>> >>> >>> Thanks, >>> >>> Christian >>> >>> >>> >>> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >>> \nvitalyd at gmail.com] >>> Sent: den 16 januari 2013 14:50 >>> To: Christian T?rnqvist >>> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >>> \nhotspot-dev at openjdk.java.net >>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>> multiprocess tests in jtreg >>> >>> >>> >>> Hi Christian, >>> >>> Not sure how polished you want/need this code to be since it's just >>> utility, but one thing that jumped out was the stream pumper threads >>> for reading stdout/err should be daemonized just to play it safe. >>> >>> There are some other things that can be done, but not sure it's worth >>> the effort for a testing utility. Let me know though if you'd like to >>> cover everything. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" >> "mailto:christian.tornqvist at oracle.com" >>> \nchristian.tornqvist at oracle.com> wrote: >>> >>> Hi everyone, >>> >>> >>> >>> This RFE adds a few utility classes to make it a bit easier to write >>> multi-process tests in jtreg, webrev can be found at >>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> Christian >>> From vladimir.x.ivanov at oracle.com Mon Jan 21 11:12:23 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 21 Jan 2013 22:12:23 +0300 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <50FD9317.4060308@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/21/13 2:48 PM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 changesets > to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From alejandro.murillo at oracle.com Mon Jan 21 13:38:33 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 21 Jan 2013 14:38:33 -0700 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <50FDB559.7090705@oracle.com> vote: yes Alejandro On 1/21/2013 4:48 AM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From coleen.phillimore at oracle.com Mon Jan 21 13:43:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Jan 2013 16:43:13 -0500 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <50FDB671.80102@oracle.com> Vote: yes On 1/21/2013 6:48 AM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From vladimir.kozlov at oracle.com Mon Jan 21 14:53:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 14:53:08 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: References: Message-ID: <50FDC6D4.6000703@oracle.com> Roland, What is effect on refworkload? I would also use it for trigonometric and math (sqrt, log) intrinsics (as separate RFE after checking performance effect). I like you factoring of sorting code in sources. Why ciConstantPoolCache::_keys is array of intptr_t and not int type elements? We'r wasting space in 64bit VM and do conversion each time we access elements. In growableArray.hpp call f(value, key) only once. In loopnode.cpp you miss 'return;' in second "if (stop_early)". It is very expensive to do build_loop_* when stop_early is true. Could you check before that if you have Expensive nodes with the same data inputs instead of just number of such nodes? Your list sorting should be cheaper. May be instead of flat list you should create list of pairs which have same data inputs, it will simplify processing code. Anyway, I think new process_expensive_nodes() method is too complex for cases which are very very rare. I think you should narrow cases for this optimization: c1 = get_control(n1); c2 = get_control(n2); if (is_dominator(c1, c2)) { c2 = c1; } else if (is_dominator(c2, c1)) { c1 = c2; } else if (c1->is_Proj() && c1->in(0)->is_If() && is_dominator(c1->in(0), c2)) { c1 = c2 = c1->in(0); } else if (c2->is_Proj() && c2->in(0)->is_If() && is_dominator(c2->in(0), c1)) { c1 = c2 = c2->in(0); } if (n1->in(0) != c1) { n1->set_req(0, c1); } if (n2->in(0) != c2) { n2->set_req(0, c2); } Note, when you skip UNC you don't check min_dom_depth but some data inputs may depend on this UNC. So it may be not safe. Thanks, Vladimir On 1/21/13 2:59 AM, Roland Westrelin wrote: > One of the method has the following structure: > > for ( .. ) { > .. > if ( ..) { > .. > } else { > if ( .. ) { > if ( .. ) { > .. > } else { > if ( .. ) { > .. > } else { > Math.pow(x, y); > } > } > } else { > if ( .. ) { > .. > } else { > Math.pow(x, y); > } > } > .. > } > > Both Math.pow(x,y) have the same inputs and so a single PowDNode is kept and it's scheduled in the else of the outer most if. So the pow computation is executed independently of the other if conditions, more frequently and because the computation is expensive there's a noticeable performance regression. > > The fix consists in: > > 1) setting the control input of the expensive nodes (PowDNode, ExpDNode) to prevent IGVN to freely common nodes > 2) During the loop optimization pass, consider each expensive node and, when possible, modify the control input to allow optimization by the IGVN while making sure it's not executed more frequently > > http://cr.openjdk.java.net/~roland/7197327/ > > To test it, given it's quite rare to have 2 PowDNodes with the same inputs, I applied the same technique to a bunch of other nodes: > > http://cr.openjdk.java.net/~roland/7197327/webrev.test/ > > Roland. > From vladimir.kozlov at oracle.com Mon Jan 21 15:33:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 15:33:24 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FDC6D4.6000703@oracle.com> References: <50FDC6D4.6000703@oracle.com> Message-ID: <50FDD044.8040409@oracle.com> On 1/21/13 2:53 PM, Vladimir Kozlov wrote: > Roland, > > What is effect on refworkload? > > I would also use it for trigonometric and math (sqrt, log) intrinsics > (as separate RFE after checking performance effect). > > I like you factoring of sorting code in sources. > > Why ciConstantPoolCache::_keys is array of intptr_t and not int type > elements? We'r wasting space in 64bit VM and do conversion each time we > access elements. > > In growableArray.hpp call f(value, key) only once. > > In loopnode.cpp you miss 'return;' in second "if (stop_early)". > > It is very expensive to do build_loop_* when stop_early is true. Could > you check before that if you have Expensive nodes with the same data > inputs instead of just number of such nodes? Your list sorting should be > cheaper. May be instead of flat list you should create list of pairs > which have same data inputs, it will simplify processing code. And you should remove control edge if there are no pairs after incremental inlining finished (no new Expensive node added). > > Anyway, I think new process_expensive_nodes() method is too complex for > cases which are very very rare. I think you should narrow cases for this > optimization: Also finding best control (move from loop) for Expensive nodes could be done in build_loop_early() method if data inputs dominate loop and the loop head is the control edge of Expensive node. Thanks, Vladimir > > c1 = get_control(n1); > c2 = get_control(n2); > > if (is_dominator(c1, c2)) { > c2 = c1; > } else if (is_dominator(c2, c1)) { > c1 = c2; > } else if (c1->is_Proj() && c1->in(0)->is_If() && > is_dominator(c1->in(0), c2)) { > c1 = c2 = c1->in(0); > } else if (c2->is_Proj() && c2->in(0)->is_If() && > is_dominator(c2->in(0), c1)) { > c1 = c2 = c2->in(0); > } > if (n1->in(0) != c1) { > n1->set_req(0, c1); > } > if (n2->in(0) != c2) { > n2->set_req(0, c2); > } > > Note, when you skip UNC you don't check min_dom_depth but some data > inputs may depend on this UNC. So it may be not safe. > > Thanks, > Vladimir > > On 1/21/13 2:59 AM, Roland Westrelin wrote: >> One of the method has the following structure: >> >> for ( .. ) { >> .. >> if ( ..) { >> .. >> } else { >> if ( .. ) { >> if ( .. ) { >> .. >> } else { >> if ( .. ) { >> .. >> } else { >> Math.pow(x, y); >> } >> } >> } else { >> if ( .. ) { >> .. >> } else { >> Math.pow(x, y); >> } >> } >> .. >> } >> >> Both Math.pow(x,y) have the same inputs and so a single PowDNode is >> kept and it's scheduled in the else of the outer most if. So the pow >> computation is executed independently of the other if conditions, more >> frequently and because the computation is expensive there's a >> noticeable performance regression. >> >> The fix consists in: >> >> 1) setting the control input of the expensive nodes (PowDNode, >> ExpDNode) to prevent IGVN to freely common nodes >> 2) During the loop optimization pass, consider each expensive node >> and, when possible, modify the control input to allow optimization by >> the IGVN while making sure it's not executed more frequently >> >> http://cr.openjdk.java.net/~roland/7197327/ >> >> To test it, given it's quite rare to have 2 PowDNodes with the same >> inputs, I applied the same technique to a bunch of other nodes: >> >> http://cr.openjdk.java.net/~roland/7197327/webrev.test/ >> >> Roland. >> From dmitry.samersoff at oracle.com Mon Jan 21 15:50:46 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Mon, 21 Jan 2013 23:50:46 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130121235053.8C82147445@hg.openjdk.java.net> Changeset: 8575a51238cb Author: dsamersoff Date: 2013-01-21 18:50 +0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8575a51238cb 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 515d98bb85f2 Author: dsamersoff Date: 2013-01-21 14:07 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/515d98bb85f2 Merge From david.holmes at oracle.com Mon Jan 21 15:59:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2013 09:59:22 +1000 Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50FD9017.1070406@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> <50FCA42D.8070307@oracle.com> <50FD9017.1070406@oracle.com> Message-ID: <50FDD65A.4070207@oracle.com> On 22/01/2013 4:59 AM, Vladimir Ivanov wrote: > > >> stdout & stderr are stored in the same buffer. I don't see why the >>> output can't be interleaved, so consequent analysis could fail >>> intermittently. I suggest to store and analyze them separately. Also, >>> it'll allow to limit the search to concrete stream. >> >> So one problem here, regardless of whether you use one buf or two is >> that there seems to be no way to correlate the output and error streams, >> unless they were already going to the same sink - in which case you >> would want them both to go to buf anyway. > I don't think that correlating streams' content is a requirement for > proposed solution. > Otherwise, more complex approach should be used here. I would always want stdout and stderr combined otherwise you can't tell how they relate. > >> Thread.interrupted call is redundant: if the thread is interrupted, > >> exception will be thrown from localIn.read call anyway. > > > > That is dependent on the underlying stream implementation and whether > > interruptible I/O is supported (which it no longer is [and only ever was > > on Solaris]). > Thanks, I wasn't aware about that. > > Shouldn't the interruption status check be reordered with read then? > >> 60 while (!Thread.interrupted() && (length = localIn.read(buffer)) > > 0) { It would be slightly better that way: - quick exit if interrupted just after start - tries to write out whatever was read in (assuming the read/write don't throw InterruptedIOException) David ----- > Best regards, > Vladimir Ivanov > >>> In the following code: >>> test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: >>> 54 public void run() { >>> 55 int length; >>> 56 try { >>> 57 byte[] buffer = new byte[BUF_SIZE]; >>> 58 InputStream localIn = in; >>> 59 OutputStream localOut = out; >>> 60 while ((length = localIn.read(buffer)) > 0 && >>> !Thread.interrupted()) { >>> 61 localOut.write(buffer, 0, length); >>> 62 } >>> 63 localOut.flush(); >>> 64 } catch (IOException e) { >>> 65 // Just abort if something like this happens. >>> 66 e.printStackTrace(); >>> 67 } >>> 68 } >>> >> >> David >> ----- >> >>> Also, I would suggest to move localOut.flush to finally clause, since >>> the call can be skipped in case of thread interruption. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >>>> Another updated webrev at >>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >>>> formatting changes. >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Christian T?rnqvist >>>> Sent: den 17 januari 2013 17:44 >>>> To: hotspot-dev at openjdk.java.net >>>> Cc: Vitaly Davidovich; Yekaterina Kantserova >>>> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >>>> multiprocess tests in jtreg >>>> >>>> Updated webrev can be found at >>>> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . Lots >>>> of small changes based on all the great feedback I got :) >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Christian T?rnqvist >>>> Sent: den 17 januari 2013 15:19 >>>> To: Vitaly Davidovich >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >>>> multiprocess tests in jtreg >>>> >>>> Hi Vitaly, >>>> >>>> First of all, thanks for all your feedback :) >>>> >>>>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>>>> for. Maybe just have an is64bitJVM() instead? You can just return >>>>> "new String[0]" though (I'm not a fan of extra >braces) >>>> >>>> This is for dealing with platform specific arguments to the java >>>> launcher (more importantly, not having the test worry about these >>>> things). Right now we only have the requirement to send '-d64' to any >>>> process launched as 64bit on Solaris, in the future we might have >>>> other requirements. That's the reason for giving this a more general >>>> name. >>>> >>>>> - there's no non-reflective way to get the pid? >>>> >>>> Not that I've found :( >>>> >>>> >>>> >>>> I've taken a lot of your comments and made changes to the classes, >>>> I'll be publishing an updated webrev soon. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> >>>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>>> Sent: den 16 januari 2013 16:30 >>>> To: Christian T?rnqvist >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: RE: RFR (S): 8006413: Add utility classes for writing better >>>> multiprocess tests in jtreg >>>> >>>> >>>> >>>> Some of this is style so feel free to ignore: >>>> >>>> I'd mark all these classes final for now. I'd also hide the default >>>> ctor for the util classes that only have static methods. >>>> >>>> JDKToolFinder >>>> - Check that the jdk.test sysprop is not empty as well. >>>> >>>> - Remove the throws clause from the method - don't think it adds any >>>> value. >>>> >>>> - RuntimeException seems more idiomatic instead of Exception >>>> >>>> - after creating the full path string, might be nice to verify that it >>>> exists and throw if not (things will not work later but you can >>>> provide a better error message here). Perhaps even return a File or >>>> Path instance instead of string. >>>> >>>> OutputAnalyzer >>>> - any reason fields are default visible? Make them private and final. >>>> >>>> - should probably check that output is not null in the constructors >>>> >>>> - it's possible to chain the constructors here >>>> >>>> - same comment about throws clauses on methods + RuntimeException as >>>> above >>>> >>>> ProcessTools >>>> - getOutput swallows IOException and returns "". Not sure this is best >>>> - I think the test should fail as you can't trust the results at this >>>> point. >>>> >>>> - StreamPumper extends Thread so I don't think you need the wrapper >>>> threads here. Cleaner is to make StreamPumper implement Runnable >>>> though and use threads here. >>>> >>>> - interruption is caught and restored but no guarantee caller will >>>> observe it now. Again, don't think returning "" is right as results >>>> are indeterminate. I'd let the interrupt bubble up. >>>> >>>> - there's no non-reflective way to get the pid? >>>> >>>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>>> for. Maybe just have an is64bitJVM() instead? You can just return "new >>>> String[0]" though (I'm not a fan of extra braces) >>>> >>>> -createJavaProcessBuilder() can probably just use >>>> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >>>> >>>> StreamPumper >>>> - check ctor args for null reference. The fields can be final as well. >>>> >>>> That's all for now :). >>>> >>>> Thanks >>>> Sent from my phone >>>> >>>> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" >>> "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.com> >>>> wrote: >>>> >>>> Hi Vitaly, >>>> >>>> >>>> >>>> Setting them as daemon sounds like a good idea :) >>>> >>>> >>>> >>>> I'd like your feedback on the other things as well, the quality of >>>> test code is important. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> >>>> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >>>> \nvitalyd at gmail.com] >>>> Sent: den 16 januari 2013 14:50 >>>> To: Christian T?rnqvist >>>> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >>>> \nhotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (S): 8006413: Add utility classes for writing better >>>> multiprocess tests in jtreg >>>> >>>> >>>> >>>> Hi Christian, >>>> >>>> Not sure how polished you want/need this code to be since it's just >>>> utility, but one thing that jumped out was the stream pumper threads >>>> for reading stdout/err should be daemonized just to play it safe. >>>> >>>> There are some other things that can be done, but not sure it's worth >>>> the effort for a testing utility. Let me know though if you'd like to >>>> cover everything. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" >>> "mailto:christian.tornqvist at oracle.com" >>>> \nchristian.tornqvist at oracle.com> wrote: >>>> >>>> Hi everyone, >>>> >>>> >>>> >>>> This RFE adds a few utility classes to make it a bit easier to write >>>> multi-process tests in jtreg, webrev can be found at >>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> From roland.westrelin at oracle.com Tue Jan 22 00:39:04 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Jan 2013 09:39:04 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FDC6D4.6000703@oracle.com> References: <50FDC6D4.6000703@oracle.com> Message-ID: <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> Hi Vladimir, Thanks for reviewing this. > What is effect on ref workload? I haven't tried yet. > I would also use it for trigonometric and math (sqrt, log) intrinsics (as separate RFE after checking performance effect). Ok. I will file an RFE. > I like you factoring of sorting code in sources. It doesn't look like you like how it's used in the new code so I guess I'll file an RFE for the clean-up if it's no longer related to this change. > Why ciConstantPoolCache::_keys is array of intptr_t and not int type elements? We'r wasting space in 64bit VM and do conversion each time we access elements. I'll file an RFE for this one as well. > In growableArray.hpp call f(value, key) only once. > > In loopnode.cpp you miss 'return;' in second "if (stop_early)". > > It is very expensive to do build_loop_* when stop_early is true. Could you check before that if you have Expensive nodes with the same data inputs instead of just number of such nodes? Your list sorting should be cheaper. May be instead of flat list you should create list of pairs which have same data inputs, it will simplify processing code. I don't understand what pairs you are referring to. There can be more than 2 identical expensive nodes in a method, right? > Anyway, I think new process_expensive_nodes() method is too complex for cases which are very very rare. I think you should narrow cases for this optimization: Are you suggesting I should drop all the process_expensive_nodes() and replace it by the code below that would be applied 2 by 2 to pair of nodes with same data inputs? > c1 = get_control(n1); > c2 = get_control(n2); > > if (is_dominator(c1, c2)) { > c2 = c1; > } else if (is_dominator(c2, c1)) { > c1 = c2; > } else if (c1->is_Proj() && c1->in(0)->is_If() && > is_dominator(c1->in(0), c2)) { > c1 = c2 = c1->in(0); > } else if (c2->is_Proj() && c2->in(0)->is_If() && > is_dominator(c2->in(0), c1)) { > c1 = c2 = c2->in(0); > } > if (n1->in(0) != c1) { > n1->set_req(0, c1); > } > if (n2->in(0) != c2) { > n2->set_req(0, c2); > } My code has 3 steps: 1- Move the node up the dominator tree along paths with same frequency 2- Handle If with same computation in both branches 3- Check for computation that dominates another computation 1- and 2- is done in a loop until no more progress. You code above does 2- and 3-. Are you suggesting 1- can be dropped? Or that there's no need for 1- and 2- as separate steps in a loop? I wrote the code in process_expensive_nodes() so that it optimizes this correctly: static double m1(double a, double b) { double r1 = 0, r2 = 0, r3 = 0; for(int i = 0; i < 10000; i++) { if (a > 0) { if (b > 0) { if (b > a) { r3 = Math.pow(a,b); r2 = Math.exp(r3); } else { r3 = Math.pow(a,b); if (b > a) { m2(); } r2 = Math.exp(r3); } } else { r3 = Math.pow(a,b); r2 = Math.exp(r3); } } else { r3 = Math.pow(a, b); r2 = Math.exp(r3); } } r3 = Math.pow(a, b); r2 = Math.exp(r3); return r1 + r2 + r3; } Roland. From christian.tornqvist at oracle.com Tue Jan 22 04:06:40 2013 From: christian.tornqvist at oracle.com (=?utf-8?B?Q2hyaXN0aWFuIFTDtnJucXZpc3Q=?=) Date: Tue, 22 Jan 2013 04:06:40 -0800 (PST) Subject: Review request: JDK-8004147 test/Makefile jtreg_tests target does not work with cygwin In-Reply-To: <50FD27B1.7000908@oracle.com> References: <50FD27B1.7000908@oracle.com> Message-ID: Hi Mikael, Might not be in scope for this change, but we should add '-retain:fail,error' to the jtreg command line, otherwise it'll only save the artifacts (including hs_err and core files) from the last executed test with status fail/error. Otherwise it looks good :) Thanks, Christian -----Original Message----- From: Mikael Gerdin Sent: den 21 januari 2013 12:34 To: hotspot-dev developers Subject: Review request: JDK-8004147 test/Makefile jtreg_tests target does not work with cygwin Hi, When trying to run the hotspot regression tests with cygwin I noticed that the paths passed to the jtreg launcher suffers from the same issue as was found in JDK-7152791. My suggested fix is to convert the paths before passing them to the jtreg launcher. Webrev: http://cr.openjdk.java.net/~mgerdin/8004147/webrev.0/ -- Mikael Gerdin Java SE VM SQE Stockholm From mikael.gerdin at oracle.com Tue Jan 22 04:39:47 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 22 Jan 2013 13:39:47 +0100 Subject: Review request: JDK-8004147 test/Makefile jtreg_tests target does not work with cygwin In-Reply-To: References: <50FD27B1.7000908@oracle.com> Message-ID: <50FE8893.2060702@oracle.com> Christian, On 2013-01-22 13:06, Christian T?rnqvist wrote: > Hi Mikael, > > Might not be in scope for this change, but we should add '-retain:fail,error' to the jtreg command line, otherwise it'll only save the artifacts (including hs_err and core files) from the last executed test with status fail/error. I agree that '-retain:fail,error' would be useful but since this particular functionality is not used by regular JPRT runs I'd rather do that as a separate fix, perhaps when/if we decide to start running jtreg tests in normal JPRT runs. /Mikael > > Otherwise it looks good :) > > Thanks, > Christian > > -----Original Message----- > From: Mikael Gerdin > Sent: den 21 januari 2013 12:34 > To: hotspot-dev developers > Subject: Review request: JDK-8004147 test/Makefile jtreg_tests target does not work with cygwin > > Hi, > > When trying to run the hotspot regression tests with cygwin I noticed that the paths passed to the jtreg launcher suffers from the same issue as was found in JDK-7152791. > > My suggested fix is to convert the paths before passing them to the jtreg launcher. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8004147/webrev.0/ > > > > -- > Mikael Gerdin > Java SE VM SQE Stockholm > -- Mikael Gerdin Java SE VM SQE Stockholm From zhengyu.gu at oracle.com Tue Jan 22 06:45:05 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 22 Jan 2013 09:45:05 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50FC9FCD.2010806@oracle.com> References: <50F992E1.6050704@oracle.com> <50FC9FCD.2010806@oracle.com> Message-ID: <50FEA5F1.90304@oracle.com> Hi David, Calvin also pointed this out, and checked JDK repo, he said there is no reference to this field. However, I think jvm_version_info is an exported structure, we can not simply remove it. My impression is that we have to update spec and depreciate it before we can safely remove it, but I am not sure. Can anyone point me the right process for removing the field? should I file a JBS bug and CCC request? Thanks, -Zhengyu On 1/20/2013 8:54 PM, David Holmes wrote: > Hi Zhengyu, > > In addition to comments already made: > > src/share/vm/prims/jvm.cpp > > info->is_kernel_jvm = 0; // false; > > Does this imply we need to update the spec and definition of > jvm_version_info? > > And are there further changes needed on the JDK side? Where is/was the > jkernel download manager class? > > Thanks, > David > > On 19/01/2013 4:22 AM, Zhengyu Gu wrote: >> Hi, >> >> This is a cleanup of kernel code, since it is already obsoleted - JDK7 >> and JDK8 are no longer building kernel. >> >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 >> Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ >> >> Tests: >> - JPRT >> - ute vm.quick.testlist on Linux x32. >> >> Thanks, >> >> -Zhengyu From zhengyu.gu at oracle.com Tue Jan 22 06:45:48 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 22 Jan 2013 09:45:48 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50FC9BB1.7060000@oracle.com> References: <50F9C403.6070700@oracle.com> <50F9C76F.4080701@oracle.com> <50FC9BB1.7060000@oracle.com> Message-ID: <50FEA61C.3020201@oracle.com> On 1/20/2013 8:36 PM, David Holmes wrote: > On 19/01/2013 8:06 AM, Zhengyu Gu wrote: >> On 1/18/2013 4:52 PM, Chris Plummer wrote: >>> src/share/vm/classfile/systemDictionary.cpp: I guess the removal of >>> the following code is correct. The original code was odd since it had >>> a kernel reference outside of #ifdef KERNEL, and then a non-kernel >>> reference (which you removed), within the "if". Just want to double >>> check that this is the right thing to do. >>> >>> 1826 if (init_opt == SystemDictionary::Opt_Kernel) { >>> 1827 #ifndef KERNEL >>> 1828 try_load = false; >>> 1829 #endif //KERNEL >>> 1830 } >> I removed SystemDictionary::Opt_Kernel. Can anyone verify if it is OK? > > Yes. Also note that the try_load flag is now always true and so can be > removed. Yes, it can be removed. I will fix it. Thanks, -Zhengyu > > David From zhengyu.gu at oracle.com Tue Jan 22 07:08:39 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 22 Jan 2013 10:08:39 -0500 Subject: Code review request: 6871190,Don't terminate JVM if it is running in a non-interactive session Message-ID: <50FEAB77.9090600@oracle.com> Hi, The fix is based on Christian's comment in JBS. JVM should not terminate the process if it is running in a non-interactive session. JBS: https://jbs.oracle.com/bugs/browse/JDK-6871190 Webrev: http://cr.openjdk.java.net/~zgu/6871190/webrev.00/ The fix is verified by Christian, thanks a lot! -Zhengyu From christian.tornqvist at oracle.com Tue Jan 22 08:17:06 2013 From: christian.tornqvist at oracle.com (=?utf-8?B?Q2hyaXN0aWFuIFTDtnJucXZpc3Q=?=) Date: Tue, 22 Jan 2013 08:17:06 -0800 (PST) Subject: Code review request: 6871190, Don't terminate JVM if it is running in a non-interactive session In-Reply-To: <50FEAB77.9090600@oracle.com> References: <50FEAB77.9090600@oracle.com> Message-ID: <3f0b34df-d558-4be6-919d-9f882aa0f23c@default> Hi Zhengyu, I seem to remember there being a discussion on that we shouldn't put bug numbers in the code/comments (this one is probably my fault for including it in my example in the bug comment though :) ). Otherwise it looks fine. Thanks, Christian -----Original Message----- From: Zhengyu Gu Sent: den 22 januari 2013 16:09 To: hotspot-dev at openjdk.java.net Cc: Christian T?rnqvist Subject: Code review request: 6871190,Don't terminate JVM if it is running in a non-interactive session Hi, The fix is based on Christian's comment in JBS. JVM should not terminate the process if it is running in a non-interactive session. JBS: https://jbs.oracle.com/bugs/browse/JDK-6871190 Webrev: http://cr.openjdk.java.net/~zgu/6871190/webrev.00/ The fix is verified by Christian, thanks a lot! -Zhengyu From joseph.provino at oracle.com Tue Jan 22 08:20:51 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 22 Jan 2013 11:20:51 -0500 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS In-Reply-To: <50EDC99B.9040109@oracle.com> References: <50EDC99B.9040109@oracle.com> Message-ID: <50FEBC63.2000308@oracle.com> Do I have final approval for this to be pushed? I'd like to push the changes today if possible. thanks. joe On 1/9/2013 2:48 PM, Joe Provino wrote: > INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. > > SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. > > The webrev is here: > http://cr.openjdk.java.net/~jprovino/8005915/webrev.01 > > Thanks. > > joe From bengt.rutisson at oracle.com Tue Jan 22 08:47:29 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 22 Jan 2013 17:47:29 +0100 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS In-Reply-To: <50FEBC63.2000308@oracle.com> References: <50EDC99B.9040109@oracle.com> <50FEBC63.2000308@oracle.com> Message-ID: <20451B68-ECAE-4253-819A-41EDBAFD3534@oracle.com> Ok for me. Bengt 22 jan 2013 kl. 17:20 skrev Joe Provino : > Do I have final approval for this to be pushed? > > I'd like to push the changes today if possible. > > thanks. > > joe > > On 1/9/2013 2:48 PM, Joe Provino wrote: >> INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. >> >> SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. >> >> The webrev is here: http://cr.openjdk.java.net/~jprovino/8005915/webrev.01 >> >> Thanks. >> >> joe From bengt.rutisson at oracle.com Tue Jan 22 10:43:08 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 22 Jan 2013 19:43:08 +0100 Subject: CFV: New HSX Committer: Mikael Gerdin Message-ID: <50FEDDBC.9090100@oracle.com> I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX Committer. Mikael is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 The last change does not list Mikael as a contributor, but this was due to a mistake on my side. He was definitely a large contributor to that fix. See: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html Votes are due by February 5, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Bengt [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From karen.kinnear at oracle.com Tue Jan 22 10:47:26 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 22 Jan 2013 13:47:26 -0500 Subject: Code review request: 6871190, Don't terminate JVM if it is running in a non-interactive session In-Reply-To: <50FEAB77.9090600@oracle.com> References: <50FEAB77.9090600@oracle.com> Message-ID: <8E7E4FA4-F3E7-4C8B-B7EF-5C902C761B33@oracle.com> Zhengyu, Looks good. Thank you for the fix. And thank you Christian for verifying this! thanks, Karen On Jan 22, 2013, at 10:08 AM, Zhengyu Gu wrote: > Hi, > > The fix is based on Christian's comment in JBS. JVM should not terminate the process if it is running in a non-interactive session. > > > JBS: https://jbs.oracle.com/bugs/browse/JDK-6871190 > Webrev: http://cr.openjdk.java.net/~zgu/6871190/webrev.00/ > > > The fix is verified by Christian, thanks a lot! > > > -Zhengyu From krystal.mo at oracle.com Tue Jan 22 11:05:09 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 23 Jan 2013 03:05:09 +0800 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FEE2E5.6030007@oracle.com> Vote: yes - Kris On 01/23/2013 02:43 AM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From jesper.wilhelmsson at oracle.com Tue Jan 22 11:10:44 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 22 Jan 2013 20:10:44 +0100 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FEE434.6030800@oracle.com> Vote: yes /Jesper On 22/1/13 7:43 PM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From staffan.larsen at oracle.com Tue Jan 22 11:25:40 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 22 Jan 2013 20:25:40 +0100 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <821F80DF-9BCA-454F-80B3-BCCEF3F5CE4B@oracle.com> Vote: yes. On 22 jan 2013, at 19:43, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was due to a mistake on my side. He was definitely a large contributor to that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From coleen.phillimore at oracle.com Tue Jan 22 11:25:00 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Jan 2013 14:25:00 -0500 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FEE78C.1050304@oracle.com> Vote: yes On 01/22/2013 01:43 PM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From vladimir.kozlov at oracle.com Tue Jan 22 11:35:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 11:35:18 -0800 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FEE9F6.2010002@oracle.com> Vote: yes On 1/22/13 10:43 AM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was due > to a mistake on my side. He was definitely a large contributor to that > fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From zhengyu.gu at oracle.com Tue Jan 22 11:40:13 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 22 Jan 2013 14:40:13 -0500 Subject: Code review request: 6871190, Don't terminate JVM if it is running in a non-interactive session In-Reply-To: <3f0b34df-d558-4be6-919d-9f882aa0f23c@default> References: <50FEAB77.9090600@oracle.com> <3f0b34df-d558-4be6-919d-9f882aa0f23c@default> Message-ID: <50FEEB1D.3060301@oracle.com> Thanks for reviewing. I will remove the bug id. -Zhengyu On 1/22/2013 11:17 AM, Christian T?rnqvist wrote: > Hi Zhengyu, > > I seem to remember there being a discussion on that we shouldn't put bug numbers in the code/comments (this one is probably my fault for including it in my example in the bug comment though :) ). > > Otherwise it looks fine. > > Thanks, > Christian > > -----Original Message----- > From: Zhengyu Gu > Sent: den 22 januari 2013 16:09 > To: hotspot-dev at openjdk.java.net > Cc: Christian T?rnqvist > Subject: Code review request: 6871190,Don't terminate JVM if it is running in a non-interactive session > > Hi, > > The fix is based on Christian's comment in JBS. JVM should not terminate the process if it is running in a non-interactive session. > > > JBS: https://jbs.oracle.com/bugs/browse/JDK-6871190 > Webrev: http://cr.openjdk.java.net/~zgu/6871190/webrev.00/ > > > The fix is verified by Christian, thanks a lot! > > > -Zhengyu From stefan.karlsson at oracle.com Tue Jan 22 11:59:17 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson (Oracle)) Date: Tue, 22 Jan 2013 20:59:17 +0100 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: vote: yes StefanK On Jan 22, 2013, at 7:43 PM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was due to a mistake on my side. He was definitely a large contributor to that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From zhengyu.gu at oracle.com Tue Jan 22 12:20:36 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 22 Jan 2013 15:20:36 -0500 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEE78C.1050304@oracle.com> References: <50FEDDBC.9090100@oracle.com> <50FEE78C.1050304@oracle.com> Message-ID: <50FEF494.5000509@oracle.com> Vote: yes -Zhengyu On 1/22/2013 2:25 PM, Coleen Phillimore wrote: > Vote: yes > > On 01/22/2013 01:43 PM, Bengt Rutisson wrote: >> >> I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX >> Committer. >> >> Mikael is a member of the Hotspot GC team. He has contributed 8 >> changesets to the HSX project and he is qualified to be committer [1]: >> >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 >> >> The last change does not list Mikael as a contributor, but this was >> due to a mistake on my side. He was definitely a large contributor to >> that fix. See: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html >> >> >> Votes are due by February 5, 2013. >> >> Only current HSX Committers [2] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Bengt >> >> [1]http://openjdk.java.net/projects/#project-committer >> [2]http://openjdk.java.net/census#hsx >> [3]http://openjdk.java.net/projects#committer-vote >> > From david.holmes at oracle.com Tue Jan 22 14:25:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 08:25:18 +1000 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FF11CE.1050609@oracle.com> Vote: yes David On 23/01/2013 4:43 AM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was due > to a mistake on my side. He was definitely a large contributor to that > fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From vladimir.x.ivanov at oracle.com Tue Jan 22 15:38:12 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 23 Jan 2013 02:38:12 +0300 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FF22E4.4000702@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/22/13 9:43 PM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was due > to a mistake on my side. He was definitely a large contributor to that > fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From alejandro.murillo at oracle.com Tue Jan 22 14:45:03 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 22 Jan 2013 15:45:03 -0700 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <50FF166F.4050700@oracle.com> vote: yes Alejandro On 1/22/2013 11:43 AM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From zhengyu.gu at oracle.com Tue Jan 22 15:29:23 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 22 Jan 2013 23:29:23 +0000 Subject: hg: hsx/hsx24/hotspot: 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Message-ID: <20130122232927.BD49A4748C@hg.openjdk.java.net> Changeset: 62eafb1b8499 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/62eafb1b8499 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp From serguei.spitsyn at oracle.com Tue Jan 22 16:07:38 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2013 16:07:38 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <50FF29CA.9000009@oracle.com> Please, review the fix for: https://jbs.oracle.com/bugs/browse/JDK-8006542 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged. Testing: vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Asked the VM SQE team to develop new INDY tests for better coverage. Thanks, Serguei From christian.tornqvist at oracle.com Wed Jan 23 01:43:04 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Wed, 23 Jan 2013 01:43:04 -0800 (PST) Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: Vote: yes -----Original Message----- From: Bengt Rutisson Sent: den 22 januari 2013 19:43 To: hotspot-dev at openjdk.java.net Subject: CFV: New HSX Committer: Mikael Gerdin I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX Committer. Mikael is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 The last change does not list Mikael as a contributor, but this was due to a mistake on my side. He was definitely a large contributor to that fix. See: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html Votes are due by February 5, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Bengt [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From christian.tornqvist at oracle.com Wed Jan 23 04:37:30 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Wed, 23 Jan 2013 04:37:30 -0800 (PST) Subject: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <50FDD65A.4070207@oracle.com> References: <361618c6-904b-4dde-bd65-fd255f0d8112@default> <2cb70d7d-fbc1-44a8-a24b-d31b841f2999@default> <829105df-e94f-4512-a97e-9608b9817bcb@default> <6a817e45-1150-411d-94b6-560c016b3353@default> <50F959B9.4070204@oracle.com> <50FCA42D.8070307@oracle.com> <50FD9017.1070406@oracle.com> <50FDD65A.4070207@oracle.com> Message-ID: <4e63175e-1b1d-4964-87b3-cb1662d1c284@default> I've changed the order of the Thread.interrupted check as suggested by David Holmes and Vladimir Ivanov. As for leaving the stdout/stderr interleaved, that is something that can easily be addressed later if there is a need for it. Thanks for all the great reviews, list of reviewers (if I've missed anyone, please let me know): brutisso, vitalyd at gmail.com, dholmes, vlivanov, nloodin, mgerdin Thanks, Christian -----Original Message----- From: David Holmes Sent: den 22 januari 2013 00:59 To: Vladimir Ivanov Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg On 22/01/2013 4:59 AM, Vladimir Ivanov wrote: > > >> stdout & stderr are stored in the same buffer. I don't see why the >>> output can't be interleaved, so consequent analysis could fail >>> intermittently. I suggest to store and analyze them separately. >>> Also, it'll allow to limit the search to concrete stream. >> >> So one problem here, regardless of whether you use one buf or two is >> that there seems to be no way to correlate the output and error >> streams, unless they were already going to the same sink - in which >> case you would want them both to go to buf anyway. > I don't think that correlating streams' content is a requirement for > proposed solution. > Otherwise, more complex approach should be used here. I would always want stdout and stderr combined otherwise you can't tell how they relate. > >> Thread.interrupted call is redundant: if the thread is > interrupted, >> exception will be thrown from localIn.read call anyway. > > > > That is dependent on the underlying stream implementation and > whether > interruptible I/O is supported (which it no longer is [and > only ever was > on Solaris]). > Thanks, I wasn't aware about that. > > Shouldn't the interruption status check be reordered with read then? > >> 60 while (!Thread.interrupted() && (length = localIn.read(buffer)) > > > 0) { It would be slightly better that way: - quick exit if interrupted just after start - tries to write out whatever was read in (assuming the read/write don't throw InterruptedIOException) David ----- > Best regards, > Vladimir Ivanov > >>> In the following code: >>> test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java: >>> 54 public void run() { >>> 55 int length; >>> 56 try { >>> 57 byte[] buffer = new byte[BUF_SIZE]; >>> 58 InputStream localIn = in; >>> 59 OutputStream localOut = out; >>> 60 while ((length = localIn.read(buffer)) > 0 && >>> !Thread.interrupted()) { >>> 61 localOut.write(buffer, 0, length); >>> 62 } >>> 63 localOut.flush(); >>> 64 } catch (IOException e) { >>> 65 // Just abort if something like this happens. >>> 66 e.printStackTrace(); >>> 67 } >>> 68 } >>> >> >> David >> ----- >> >>> Also, I would suggest to move localOut.flush to finally clause, >>> since the call can be skipped in case of thread interruption. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 1/18/13 3:43 PM, Christian T?rnqvist wrote: >>>> Another updated webrev at >>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.02/ , >>>> formatting changes. >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Christian T?rnqvist >>>> Sent: den 17 januari 2013 17:44 >>>> To: hotspot-dev at openjdk.java.net >>>> Cc: Vitaly Davidovich; Yekaterina Kantserova >>>> Subject: RE: RFR (S): 8006413: Add utility classes for writing >>>> better multiprocess tests in jtreg >>>> >>>> Updated webrev can be found at >>>> http://cr.openjdk.java.net/~mgerdin/ctornqvi/8006413/webrev.01/ . >>>> Lots of small changes based on all the great feedback I got :) >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Christian T?rnqvist >>>> Sent: den 17 januari 2013 15:19 >>>> To: Vitaly Davidovich >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: RE: RFR (S): 8006413: Add utility classes for writing >>>> better multiprocess tests in jtreg >>>> >>>> Hi Vitaly, >>>> >>>> First of all, thanks for all your feedback :) >>>> >>>>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>>>> for. Maybe just have an is64bitJVM() instead? You can just return >>>>> "new String[0]" though (I'm not a fan of extra >braces) >>>> >>>> This is for dealing with platform specific arguments to the java >>>> launcher (more importantly, not having the test worry about these >>>> things). Right now we only have the requirement to send '-d64' to >>>> any process launched as 64bit on Solaris, in the future we might >>>> have other requirements. That's the reason for giving this a more >>>> general name. >>>> >>>>> - there's no non-reflective way to get the pid? >>>> >>>> Not that I've found :( >>>> >>>> >>>> >>>> I've taken a lot of your comments and made changes to the classes, >>>> I'll be publishing an updated webrev soon. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> >>>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>>> Sent: den 16 januari 2013 16:30 >>>> To: Christian T?rnqvist >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: RE: RFR (S): 8006413: Add utility classes for writing >>>> better multiprocess tests in jtreg >>>> >>>> >>>> >>>> Some of this is style so feel free to ignore: >>>> >>>> I'd mark all these classes final for now. I'd also hide the default >>>> ctor for the util classes that only have static methods. >>>> >>>> JDKToolFinder >>>> - Check that the jdk.test sysprop is not empty as well. >>>> >>>> - Remove the throws clause from the method - don't think it adds >>>> any value. >>>> >>>> - RuntimeException seems more idiomatic instead of Exception >>>> >>>> - after creating the full path string, might be nice to verify that >>>> it exists and throw if not (things will not work later but you can >>>> provide a better error message here). Perhaps even return a File or >>>> Path instance instead of string. >>>> >>>> OutputAnalyzer >>>> - any reason fields are default visible? Make them private and final. >>>> >>>> - should probably check that output is not null in the constructors >>>> >>>> - it's possible to chain the constructors here >>>> >>>> - same comment about throws clauses on methods + RuntimeException >>>> as above >>>> >>>> ProcessTools >>>> - getOutput swallows IOException and returns "". Not sure this is >>>> best >>>> - I think the test should fail as you can't trust the results at >>>> this point. >>>> >>>> - StreamPumper extends Thread so I don't think you need the wrapper >>>> threads here. Cleaner is to make StreamPumper implement Runnable >>>> though and use threads here. >>>> >>>> - interruption is caught and restored but no guarantee caller will >>>> observe it now. Again, don't think returning "" is right as results >>>> are indeterminate. I'd let the interrupt bubble up. >>>> >>>> - there's no non-reflective way to get the pid? >>>> >>>> - not entirely sure what getPlatformSpecificVMArgs is really meant >>>> for. Maybe just have an is64bitJVM() instead? You can just return >>>> "new String[0]" though (I'm not a fan of extra braces) >>>> >>>> -createJavaProcessBuilder() can probably just use >>>> List.addAll(Arrays.asList(...)) but Collections. addAll is OK too. >>>> >>>> StreamPumper >>>> - check ctor args for null reference. The fields can be final as well. >>>> >>>> That's all for now :). >>>> >>>> Thanks >>>> Sent from my phone >>>> >>>> On Jan 16, 2013 9:42 AM, "Christian T?rnqvist" >>> "mailto:christian.tornqvist at oracle.com"christian.tornqvist at oracle.c >>>> om> >>>> wrote: >>>> >>>> Hi Vitaly, >>>> >>>> >>>> >>>> Setting them as daemon sounds like a good idea :) >>>> >>>> >>>> >>>> I'd like your feedback on the other things as well, the quality of >>>> test code is important. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> >>>> From: Vitaly Davidovich [mailto:HYPERLINK "mailto:vitalyd at gmail.com" >>>> \nvitalyd at gmail.com] >>>> Sent: den 16 januari 2013 14:50 >>>> To: Christian T?rnqvist >>>> Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net" >>>> \nhotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (S): 8006413: Add utility classes for writing >>>> better multiprocess tests in jtreg >>>> >>>> >>>> >>>> Hi Christian, >>>> >>>> Not sure how polished you want/need this code to be since it's just >>>> utility, but one thing that jumped out was the stream pumper >>>> threads for reading stdout/err should be daemonized just to play it safe. >>>> >>>> There are some other things that can be done, but not sure it's >>>> worth the effort for a testing utility. Let me know though if you'd >>>> like to cover everything. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 16, 2013 7:36 AM, "Christian T?rnqvist" >>> "mailto:christian.tornqvist at oracle.com" >>>> \nchristian.tornqvist at oracle.com> wrote: >>>> >>>> Hi everyone, >>>> >>>> >>>> >>>> This RFE adds a few utility classes to make it a bit easier to >>>> write multi-process tests in jtreg, webrev can be found at >>>> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> From zhengyu.gu at oracle.com Wed Jan 23 07:02:16 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 23 Jan 2013 10:02:16 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50F992E1.6050704@oracle.com> References: <50F992E1.6050704@oracle.com> Message-ID: <50FFFB78.50504@oracle.com> I updated webrev, based on the comments from David, Chris and Karen, etc. Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.01/ I also filed JBS bug 8006691 (https://jbs.oracle.com/bugs/browse/JDK-8006691) to track the removal of is_kernel_vm field in jvm_version_info structure. Thanks, -Zhengyu On 1/18/2013 1:22 PM, Zhengyu Gu wrote: > Hi, > > This is a cleanup of kernel code, since it is already obsoleted - JDK7 > and JDK8 are no longer building kernel. > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 > Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ > > Tests: > - JPRT > - ute vm.quick.testlist on Linux x32. > > Thanks, > > -Zhengyu From coleen.phillimore at oracle.com Wed Jan 23 08:46:57 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Jan 2013 11:46:57 -0500 Subject: Request for review: Unify SERIALGC and INCLUDE_ALTERNATE_GCS In-Reply-To: <20451B68-ECAE-4253-819A-41EDBAFD3534@oracle.com> References: <50EDC99B.9040109@oracle.com> <50FEBC63.2000308@oracle.com> <20451B68-ECAE-4253-819A-41EDBAFD3534@oracle.com> Message-ID: <51001401.6010800@oracle.com> Me too. Coleen On 01/22/2013 11:47 AM, Bengt Rutisson wrote: > Ok for me. > > Bengt > > 22 jan 2013 kl. 17:20 skrev Joe Provino : > >> Do I have final approval for this to be pushed? >> >> I'd like to push the changes today if possible. >> >> thanks. >> >> joe >> >> On 1/9/2013 2:48 PM, Joe Provino wrote: >>> INCLUDE_ALTERNATE_GCS has been changed to INCLUDE_ALL_GCS. >>> >>> SERIALGC has been removed and INCLUDE_ALL_GCS is used instead. >>> >>> The webrev is here: http://cr.openjdk.java.net/~jprovino/8005915/webrev.01 >>> >>> Thanks. >>> >>> joe From zhengyu.gu at oracle.com Wed Jan 23 10:47:29 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 23 Jan 2013 18:47:29 +0000 Subject: hg: hsx/hsx24/hotspot: 8005936: PrintNMTStatistics doesn't work for normal JVM exit Message-ID: <20130123184734.6BDDE474D8@hg.openjdk.java.net> Changeset: c28e0cb8d005 Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c28e0cb8d005 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp From vladimir.kozlov at oracle.com Wed Jan 23 11:50:10 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 23 Jan 2013 19:50:10 +0000 Subject: hg: hsx/hotspot-main/jdk: 8006799: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() (jdk part of 6896617) Message-ID: <20130123195101.2A851474E0@hg.openjdk.java.net> Changeset: 739351a0a7a1 Author: kvn Date: 2013-01-23 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/739351a0a7a1 8006799: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() (jdk part of 6896617) Summary: Move hot loop in ISO_8859_1$Encode.encodeArrayLoop() into separate method encodeISOArray() to be replaced by JVM JIT compiler with optimized intrinsic code. Reviewed-by: alanb, sherman ! src/share/classes/sun/nio/cs/ISO_8859_1.java From karen.kinnear at oracle.com Wed Jan 23 17:32:26 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 24 Jan 2013 01:32:26 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130124013246.BFEED474FD@hg.openjdk.java.net> Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp From david.holmes at oracle.com Wed Jan 23 18:32:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 12:32:55 +1000 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <50FFFB78.50504@oracle.com> References: <50F992E1.6050704@oracle.com> <50FFFB78.50504@oracle.com> Message-ID: <51009D57.20307@oracle.com> Looks good to me. Once question: I can not find sun.jkernel.DownloadManager anywhere (open or closed repos). Has this already been removed? David On 24/01/2013 1:02 AM, Zhengyu Gu wrote: > I updated webrev, based on the comments from David, Chris and Karen, etc. > > Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.01/ > > I also filed JBS bug 8006691 > (https://jbs.oracle.com/bugs/browse/JDK-8006691) to track the removal of > is_kernel_vm field in jvm_version_info structure. > > Thanks, > > -Zhengyu > > On 1/18/2013 1:22 PM, Zhengyu Gu wrote: >> Hi, >> >> This is a cleanup of kernel code, since it is already obsoleted - JDK7 >> and JDK8 are no longer building kernel. >> >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 >> Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ >> >> Tests: >> - JPRT >> - ute vm.quick.testlist on Linux x32. >> >> Thanks, >> >> -Zhengyu From vladimir.kozlov at oracle.com Wed Jan 23 20:03:04 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 24 Jan 2013 04:03:04 +0000 Subject: hg: hsx/hsx24/hotspot: 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Message-ID: <20130124040309.1FFAD47504@hg.openjdk.java.net> Changeset: 24aa4f99d1aa Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/24aa4f99d1aa 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp From krystal.mo at oracle.com Thu Jan 24 00:06:46 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 16:06:46 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) Message-ID: <5100EB96.3030409@oracle.com> Hi all, Could anyone review this patch, please? It's causing a lot of failures in nightlies, so I'd like to get it reviewed quickly and push it ASAP. Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 (There's no public bug for this yet. The description is copied below.) Bug to cover recent nightly failures with: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, tid=2731850608 # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic || resolved_method->is_compiled_lambda_form()) failed: linkMethod must return one of these # # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, sharing linux-x86 ) # Core dump written. Default location: XXX/core or core.7993 # # An error report file with more information is saved as: # XXX/hs_err_pid7993.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # This assertion is caused by a predicate on code privilege in ClassFileParser::AnnotationCollector::annotation_index(): bool privileged = false; if (loader_data->is_the_null_class_loader_data()) { // Privileged code can use all annotations. Other code silently drops some. privileged = true; } The problematic code was introduced in the @Contended change, JDK-8003985: Support @Contended Annotation - JEP 142 It didn't take into account that, with recent NPG changes for 292, every anonymous class would have a dedicated ClassLoaderData which is not the null_CLD, so the condition for privileged code was not complete. The way how this code triggers the assertion far away goes like this: (1) The new MethodHandle implementation for 292 via LambdaForm uses anonymous classes to represent "compiled lambda forms". (2) The sole method in compiled lambda forms is marked with three special marker annotations: @Hidden, @Compiled and @ForceInline. (3) There's special handling in the VM to recognized these annotations while parsing the class file; but these annotations are handled specially only when the class is privileged, otherwise the special handling for them is ignored silently. (4) That information is later used to tell if a Method is a compiled lambda form. This bug introduced an incomplete predicate for code privilege in (3), silently missed the special handling, and then triggered an assertion in (4). The fix is to treat all anonymous classes as privileged code. This is assumed to be safe in an internal discussion thread. --- a/src/share/vm/classfile/classFileParser.cpp +++ b/src/share/vm/classfile/classFileParser.cpp @@ -1802,11 +1802,9 @@ ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* loader_data, Symbol* name) { vmSymbols::SID sid = vmSymbols::find_sid(name); - bool privileged = false; - if (loader_data->is_the_null_class_loader_data()) { - // Privileged code can use all annotations. Other code silently drops some. - privileged = true; - } + // Privileged code can use all annotations. Other code silently drops some. + bool privileged = loader_data->is_the_null_class_loader_data() || + loader_data->is_anonymous(); switch (sid) { case vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): if (_location != _in_method) break; // only allow for methods Thanks, Kris From krystal.mo at oracle.com Thu Jan 24 00:14:07 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 16:14:07 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100EB96.3030409@oracle.com> References: <5100EB96.3030409@oracle.com> Message-ID: <5100ED4F.5010805@oracle.com> The fix is being tested with (1) JPRT, (2) jtreg compiler and (3) jtreg java/lang/invoke I'm seeing some javac compilation timeouts in (3), but the tests that built fine are passing. Will update on test results when all three tests finish. - Kris On 01/24/2013 04:06 PM, Krystal Mo wrote: > Hi all, > > Could anyone review this patch, please? > It's causing a lot of failures in nightlies, so I'd like to get it > reviewed quickly and push it ASAP. > > Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ > Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 > (There's no public bug for this yet. The description is copied below.) > > Bug to cover recent nightly failures with: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, > tid=2731850608 > # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic > || resolved_method->is_compiled_lambda_form()) failed: linkMethod must > return one of these > # > # JRE version: Java(TM) SE Runtime Environment (8.0) (build > 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) > # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled > mode, sharing linux-x86 ) > # Core dump written. Default location: XXX/core or core.7993 > # > # An error report file with more information is saved as: > # XXX/hs_err_pid7993.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > This assertion is caused by a predicate on code privilege in > ClassFileParser::AnnotationCollector::annotation_index(): > > bool privileged = false; > if (loader_data->is_the_null_class_loader_data()) { > // Privileged code can use all annotations. Other code silently > drops some. > privileged = true; > } > > The problematic code was introduced in the @Contended change, > JDK-8003985: Support @Contended Annotation - JEP 142 > It didn't take into account that, with recent NPG changes for 292, > every anonymous class would have a dedicated ClassLoaderData which is > not the null_CLD, so the condition for privileged code was not complete. > > The way how this code triggers the assertion far away goes like this: > > (1) The new MethodHandle implementation for 292 via LambdaForm uses > anonymous classes to represent "compiled lambda forms". > (2) The sole method in compiled lambda forms is marked with three > special marker annotations: @Hidden, @Compiled and @ForceInline. > (3) There's special handling in the VM to recognized these annotations > while parsing the class file; but these annotations are handled > specially only when the class is privileged, otherwise the special > handling for them is ignored silently. > (4) That information is later used to tell if a Method is a compiled > lambda form. > > This bug introduced an incomplete predicate for code privilege in (3), > silently missed the special handling, and then triggered an assertion > in (4). > > The fix is to treat all anonymous classes as privileged code. This is > assumed to be safe in an internal discussion thread. > > --- a/src/share/vm/classfile/classFileParser.cpp > +++ b/src/share/vm/classfile/classFileParser.cpp > @@ -1802,11 +1802,9 @@ > ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* > loader_data, > Symbol* name) { > vmSymbols::SID sid = vmSymbols::find_sid(name); > - bool privileged = false; > - if (loader_data->is_the_null_class_loader_data()) { > - // Privileged code can use all annotations. Other code silently > drops some. > - privileged = true; > - } > + // Privileged code can use all annotations. Other code silently > drops some. > + bool privileged = loader_data->is_the_null_class_loader_data() || > + loader_data->is_anonymous(); > switch (sid) { > case > vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): > if (_location != _in_method) break; // only allow for methods > > Thanks, > Kris From vladimir.kozlov at oracle.com Thu Jan 24 00:31:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Jan 2013 00:31:31 -0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100EB96.3030409@oracle.com> References: <5100EB96.3030409@oracle.com> Message-ID: <5100F163.4090302@oracle.com> Looks good. Thanks, Vladimir On 1/24/13 12:06 AM, Krystal Mo wrote: > Hi all, > > Could anyone review this patch, please? > It's causing a lot of failures in nightlies, so I'd like to get it > reviewed quickly and push it ASAP. > > Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ > Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 > (There's no public bug for this yet. The description is copied below.) > > Bug to cover recent nightly failures with: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, > tid=2731850608 > # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic > || resolved_method->is_compiled_lambda_form()) failed: linkMethod must > return one of these > # > # JRE version: Java(TM) SE Runtime Environment (8.0) (build > 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) > # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, > sharing linux-x86 ) > # Core dump written. Default location: XXX/core or core.7993 > # > # An error report file with more information is saved as: > # XXX/hs_err_pid7993.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > This assertion is caused by a predicate on code privilege in > ClassFileParser::AnnotationCollector::annotation_index(): > > bool privileged = false; > if (loader_data->is_the_null_class_loader_data()) { > // Privileged code can use all annotations. Other code silently > drops some. > privileged = true; > } > > The problematic code was introduced in the @Contended change, > JDK-8003985: Support @Contended Annotation - JEP 142 > It didn't take into account that, with recent NPG changes for 292, every > anonymous class would have a dedicated ClassLoaderData which is not the > null_CLD, so the condition for privileged code was not complete. > > The way how this code triggers the assertion far away goes like this: > > (1) The new MethodHandle implementation for 292 via LambdaForm uses > anonymous classes to represent "compiled lambda forms". > (2) The sole method in compiled lambda forms is marked with three > special marker annotations: @Hidden, @Compiled and @ForceInline. > (3) There's special handling in the VM to recognized these annotations > while parsing the class file; but these annotations are handled > specially only when the class is privileged, otherwise the special > handling for them is ignored silently. > (4) That information is later used to tell if a Method is a compiled > lambda form. > > This bug introduced an incomplete predicate for code privilege in (3), > silently missed the special handling, and then triggered an assertion in > (4). > > The fix is to treat all anonymous classes as privileged code. This is > assumed to be safe in an internal discussion thread. > > --- a/src/share/vm/classfile/classFileParser.cpp > +++ b/src/share/vm/classfile/classFileParser.cpp > @@ -1802,11 +1802,9 @@ > ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* loader_data, > Symbol* name) { > vmSymbols::SID sid = vmSymbols::find_sid(name); > - bool privileged = false; > - if (loader_data->is_the_null_class_loader_data()) { > - // Privileged code can use all annotations. Other code silently > drops some. > - privileged = true; > - } > + // Privileged code can use all annotations. Other code silently > drops some. > + bool privileged = loader_data->is_the_null_class_loader_data() || > + loader_data->is_anonymous(); > switch (sid) { > case > vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): > if (_location != _in_method) break; // only allow for methods > > Thanks, > Kris From krystal.mo at oracle.com Thu Jan 24 00:41:47 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 16:41:47 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100F163.4090302@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F163.4090302@oracle.com> Message-ID: <5100F3CB.40409@oracle.com> Thank you, Vladimir. - Kris On 01/24/2013 04:31 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 1/24/13 12:06 AM, Krystal Mo wrote: >> Hi all, >> >> Could anyone review this patch, please? >> It's causing a lot of failures in nightlies, so I'd like to get it >> reviewed quickly and push it ASAP. >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 >> (There's no public bug for this yet. The description is copied below.) >> >> Bug to cover recent nightly failures with: >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, >> tid=2731850608 >> # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic >> || resolved_method->is_compiled_lambda_form()) failed: linkMethod must >> return one of these >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0) (build >> 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) >> # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, >> sharing linux-x86 ) >> # Core dump written. Default location: XXX/core or core.7993 >> # >> # An error report file with more information is saved as: >> # XXX/hs_err_pid7993.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> >> This assertion is caused by a predicate on code privilege in >> ClassFileParser::AnnotationCollector::annotation_index(): >> >> bool privileged = false; >> if (loader_data->is_the_null_class_loader_data()) { >> // Privileged code can use all annotations. Other code silently >> drops some. >> privileged = true; >> } >> >> The problematic code was introduced in the @Contended change, >> JDK-8003985: Support @Contended Annotation - JEP 142 >> It didn't take into account that, with recent NPG changes for 292, every >> anonymous class would have a dedicated ClassLoaderData which is not the >> null_CLD, so the condition for privileged code was not complete. >> >> The way how this code triggers the assertion far away goes like this: >> >> (1) The new MethodHandle implementation for 292 via LambdaForm uses >> anonymous classes to represent "compiled lambda forms". >> (2) The sole method in compiled lambda forms is marked with three >> special marker annotations: @Hidden, @Compiled and @ForceInline. >> (3) There's special handling in the VM to recognized these annotations >> while parsing the class file; but these annotations are handled >> specially only when the class is privileged, otherwise the special >> handling for them is ignored silently. >> (4) That information is later used to tell if a Method is a compiled >> lambda form. >> >> This bug introduced an incomplete predicate for code privilege in (3), >> silently missed the special handling, and then triggered an assertion in >> (4). >> >> The fix is to treat all anonymous classes as privileged code. This is >> assumed to be safe in an internal discussion thread. >> >> --- a/src/share/vm/classfile/classFileParser.cpp >> +++ b/src/share/vm/classfile/classFileParser.cpp >> @@ -1802,11 +1802,9 @@ >> ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* >> loader_data, >> Symbol* name) { >> vmSymbols::SID sid = vmSymbols::find_sid(name); >> - bool privileged = false; >> - if (loader_data->is_the_null_class_loader_data()) { >> - // Privileged code can use all annotations. Other code silently >> drops some. >> - privileged = true; >> - } >> + // Privileged code can use all annotations. Other code silently >> drops some. >> + bool privileged = loader_data->is_the_null_class_loader_data() || >> + loader_data->is_anonymous(); >> switch (sid) { >> case >> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >> if (_location != _in_method) break; // only allow for methods >> >> Thanks, >> Kris From david.holmes at oracle.com Thu Jan 24 00:53:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 18:53:34 +1000 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100EB96.3030409@oracle.com> References: <5100EB96.3030409@oracle.com> Message-ID: <5100F68E.8090509@oracle.com> Hi Kris, On 24/01/2013 6:06 PM, Krystal Mo wrote: > Hi all, > > Could anyone review this patch, please? Based on your description this patch seems to address the immediate problem. My concern is whether this whole "privileged" notion that @Contended introduced is actually valid? Is this how the constraint that @Contended can only be applied to classes on the bootclasspath was implemented? I'd also like to know what tests needed to be run to catch this. Maybe we need to add some jsr292 tests to JPRT? Thanks, David > It's causing a lot of failures in nightlies, so I'd like to get it > reviewed quickly and push it ASAP. > > Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ > Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 > (There's no public bug for this yet. The description is copied below.) > > Bug to cover recent nightly failures with: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, > tid=2731850608 > # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic > || resolved_method->is_compiled_lambda_form()) failed: linkMethod must > return one of these > # > # JRE version: Java(TM) SE Runtime Environment (8.0) (build > 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) > # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, > sharing linux-x86 ) > # Core dump written. Default location: XXX/core or core.7993 > # > # An error report file with more information is saved as: > # XXX/hs_err_pid7993.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > This assertion is caused by a predicate on code privilege in > ClassFileParser::AnnotationCollector::annotation_index(): > > bool privileged = false; > if (loader_data->is_the_null_class_loader_data()) { > // Privileged code can use all annotations. Other code silently drops some. > privileged = true; > } > > The problematic code was introduced in the @Contended change, > JDK-8003985: Support @Contended Annotation - JEP 142 > It didn't take into account that, with recent NPG changes for 292, every > anonymous class would have a dedicated ClassLoaderData which is not the > null_CLD, so the condition for privileged code was not complete. > > The way how this code triggers the assertion far away goes like this: > > (1) The new MethodHandle implementation for 292 via LambdaForm uses > anonymous classes to represent "compiled lambda forms". > (2) The sole method in compiled lambda forms is marked with three > special marker annotations: @Hidden, @Compiled and @ForceInline. > (3) There's special handling in the VM to recognized these annotations > while parsing the class file; but these annotations are handled > specially only when the class is privileged, otherwise the special > handling for them is ignored silently. > (4) That information is later used to tell if a Method is a compiled > lambda form. > > This bug introduced an incomplete predicate for code privilege in (3), > silently missed the special handling, and then triggered an assertion in > (4). > > The fix is to treat all anonymous classes as privileged code. This is > assumed to be safe in an internal discussion thread. > > --- a/src/share/vm/classfile/classFileParser.cpp > +++ b/src/share/vm/classfile/classFileParser.cpp > @@ -1802,11 +1802,9 @@ > ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* > loader_data, > Symbol* name) { > vmSymbols::SID sid = vmSymbols::find_sid(name); > - bool privileged = false; > - if (loader_data->is_the_null_class_loader_data()) { > - // Privileged code can use all annotations. Other code silently drops > some. > - privileged = true; > - } > + // Privileged code can use all annotations. Other code silently drops > some. > + bool privileged = loader_data->is_the_null_class_loader_data() || > + loader_data->is_anonymous(); > switch (sid) { > case > vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): > if (_location != _in_method) break; // only allow for methods > > Thanks, > Kris From aleksey.shipilev at oracle.com Thu Jan 24 01:03:25 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Jan 2013 13:03:25 +0400 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100F68E.8090509@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> Message-ID: <5100F8DD.2070500@oracle.com> Hi David, On 01/24/2013 12:53 PM, David Holmes wrote: > Based on your description this patch seems to address the immediate > problem. I think it is intrinsically valid given the "sun.misc.* booby trap everything" policy is being enforced. > My concern is whether this whole "privileged" notion that @Contended > introduced is actually valid? Is this how the constraint that @Contended > can only be applied to classes on the bootclasspath was implemented? This was discussed a numerous times at this list, e.g. here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-December/007502.html The current consensus is that sun.misc.* members should be unaccessible/noop-ed for unprivileged classes. This applies as the general rule, and some annotations can have the exception with the VM flag (-XX:-RestrictContended in this case). -Aleksey. From krystal.mo at oracle.com Thu Jan 24 01:10:48 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 01:10:48 -0800 (PST) Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100F68E.8090509@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> Message-ID: <5100FA98.8040806@oracle.com> David, Thanks for the review. Comments inline: On 01/24/2013 04:53 PM, David Holmes wrote: > Hi Kris, > > On 24/01/2013 6:06 PM, Krystal Mo wrote: >> Hi all, >> >> Could anyone review this patch, please? > > Based on your description this patch seems to address the immediate > problem. > Yes. But that "immediate problem" is causing a lot of JSR 292 test failures, and we got a "nogo" for hs25-b16 PIT, so it's urgent to at least get the immediate problem fixed. There's plans to add some jtreg tests to exercise this bug specifically, in a separate RFE. > My concern is whether this whole "privileged" notion that @Contended > introduced is actually valid? Is this how the constraint that > @Contended can only be applied to classes on the bootclasspath was > implemented? > Yes, the predicate in this bug is how @Contended only works for code on BCP. The notion of "privileged code" mentioned by John Rose equals to "code on bootclasspath", or in other words "core library code". Traditionally there's been a lot of privilege checks in the JDK in the form of "x.getClass().getClassLoader() == null", and it's just the same here. > I'd also like to know what tests needed to be run to catch this. Maybe > we need to add some jsr292 tests to JPRT? > With regards to adding JSR 292 tests to JPRT, I'm open to discussions. We'd need more input from John and Christian. Thanks, Kris > Thanks, > David > >> It's causing a lot of failures in nightlies, so I'd like to get it >> reviewed quickly and push it ASAP. >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 >> (There's no public bug for this yet. The description is copied below.) >> >> Bug to cover recent nightly failures with: >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, >> tid=2731850608 >> # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic >> || resolved_method->is_compiled_lambda_form()) failed: linkMethod must >> return one of these >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0) (build >> 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) >> # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, >> sharing linux-x86 ) >> # Core dump written. Default location: XXX/core or core.7993 >> # >> # An error report file with more information is saved as: >> # XXX/hs_err_pid7993.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> >> This assertion is caused by a predicate on code privilege in >> ClassFileParser::AnnotationCollector::annotation_index(): >> >> bool privileged = false; >> if (loader_data->is_the_null_class_loader_data()) { >> // Privileged code can use all annotations. Other code silently drops >> some. >> privileged = true; >> } >> >> The problematic code was introduced in the @Contended change, >> JDK-8003985: Support @Contended Annotation - JEP 142 >> It didn't take into account that, with recent NPG changes for 292, every >> anonymous class would have a dedicated ClassLoaderData which is not the >> null_CLD, so the condition for privileged code was not complete. >> >> The way how this code triggers the assertion far away goes like this: >> >> (1) The new MethodHandle implementation for 292 via LambdaForm uses >> anonymous classes to represent "compiled lambda forms". >> (2) The sole method in compiled lambda forms is marked with three >> special marker annotations: @Hidden, @Compiled and @ForceInline. >> (3) There's special handling in the VM to recognized these annotations >> while parsing the class file; but these annotations are handled >> specially only when the class is privileged, otherwise the special >> handling for them is ignored silently. >> (4) That information is later used to tell if a Method is a compiled >> lambda form. >> >> This bug introduced an incomplete predicate for code privilege in (3), >> silently missed the special handling, and then triggered an assertion in >> (4). >> >> The fix is to treat all anonymous classes as privileged code. This is >> assumed to be safe in an internal discussion thread. >> >> --- a/src/share/vm/classfile/classFileParser.cpp >> +++ b/src/share/vm/classfile/classFileParser.cpp >> @@ -1802,11 +1802,9 @@ >> ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* >> loader_data, >> Symbol* name) { >> vmSymbols::SID sid = vmSymbols::find_sid(name); >> - bool privileged = false; >> - if (loader_data->is_the_null_class_loader_data()) { >> - // Privileged code can use all annotations. Other code silently drops >> some. >> - privileged = true; >> - } >> + // Privileged code can use all annotations. Other code silently drops >> some. >> + bool privileged = loader_data->is_the_null_class_loader_data() || >> + loader_data->is_anonymous(); >> switch (sid) { >> case >> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >> if (_location != _in_method) break; // only allow for methods >> >> Thanks, >> Kris From krystal.mo at oracle.com Thu Jan 24 01:18:02 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 17:18:02 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100F8DD.2070500@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <5100F8DD.2070500@oracle.com> Message-ID: <5100FC4A.5040804@oracle.com> Aleksey, Thanks for you explanation. Comments below: On 01/24/2013 05:03 PM, Aleksey Shipilev wrote: > This was discussed a numerous times at this list, e.g. here: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-December/007502.html > > The current consensus is that sun.misc.* members should be > unaccessible/noop-ed for unprivileged classes. This applies as the > general rule, and some annotations can have the exception with the VM > flag (-XX:-RestrictContended in this case). Actually I'm a little bit confused on the noop consensus. It'd work perfectly fine for @Contended, because it's only a optional marker for performance. But the JSR 292 annotations, at least @Compiled, are mandatory annotations used for core functionalities. Silently noop-ing them can be disastrous, as we've seen in this bug. Maybe we should add an assertion when a @Compiled is found on unprivileged code, to catch the problem right there. Thanks, Kris > -Aleksey. > From aleksey.shipilev at oracle.com Thu Jan 24 01:25:42 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Jan 2013 13:25:42 +0400 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100FC4A.5040804@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <5100F8DD.2070500@oracle.com> <5100FC4A.5040804@oracle.com> Message-ID: <5100FE16.20902@oracle.com> On 01/24/2013 01:18 PM, Krystal Mo wrote: > But the JSR 292 annotations, at least @Compiled, are mandatory > annotations used for core functionalities. Silently noop-ing them can be > disastrous, as we've seen in this bug. That's right, and we need to hear John's opinion on this, because it was his original idea to booby trap these annotations along with the JSR292 annotations. Which, I presume, was considered as the potentially breaking change, but given the VM annotations are injected from the VM code it was presumed the assert would not actually fire anyway? (Which again was proven wrong in this incident). > Maybe we should add an assertion when a @Compiled is found on > unprivileged code, to catch the problem right there. That's a good idea. Debug builds should be failing with understandable asserts. -Aleksey. From david.holmes at oracle.com Thu Jan 24 01:33:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 19:33:19 +1000 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100F8DD.2070500@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <5100F8DD.2070500@oracle.com> Message-ID: <5100FFDF.5060507@oracle.com> Hi Aleksey, On 24/01/2013 7:03 PM, Aleksey Shipilev wrote: > Hi David, > > On 01/24/2013 12:53 PM, David Holmes wrote: >> Based on your description this patch seems to address the immediate >> problem. > > I think it is intrinsically valid given the "sun.misc.* booby trap > everything" policy is being enforced. > >> My concern is whether this whole "privileged" notion that @Contended >> introduced is actually valid? Is this how the constraint that @Contended >> can only be applied to classes on the bootclasspath was implemented? > > This was discussed a numerous times at this list, e.g. here: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-December/007502.html > > The current consensus is that sun.misc.* members should be > unaccessible/noop-ed for unprivileged classes. This applies as the > general rule, and some annotations can have the exception with the VM > flag (-XX:-RestrictContended in this case). It's not the policy I was questioning but the implementation. Given all the different notions of "privilege" that already exist this seems somewhat adhoc and slightly crude. But that is with hindsight. David > -Aleksey. > From david.holmes at oracle.com Thu Jan 24 01:36:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 19:36:18 +1000 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100FA98.8040806@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <5100FA98.8040806@oracle.com> Message-ID: <51010092.8090509@oracle.com> On 24/01/2013 7:10 PM, Krystal Mo wrote: > David, > > Thanks for the review. Comments inline: > > On 01/24/2013 04:53 PM, David Holmes wrote: >> Hi Kris, >> >> On 24/01/2013 6:06 PM, Krystal Mo wrote: >>> Hi all, >>> >>> Could anyone review this patch, please? >> >> Based on your description this patch seems to address the immediate >> problem. >> > Yes. But that "immediate problem" is causing a lot of JSR 292 test > failures, and we got a "nogo" for hs25-b16 PIT, so it's urgent to at > least get the immediate problem fixed. Understood - you can consider this Reviewed. Thanks, David ------ > There's plans to add some jtreg tests to exercise this bug specifically, > in a separate RFE. > >> My concern is whether this whole "privileged" notion that @Contended >> introduced is actually valid? Is this how the constraint that >> @Contended can only be applied to classes on the bootclasspath was >> implemented? >> > > Yes, the predicate in this bug is how @Contended only works for code on > BCP. > The notion of "privileged code" mentioned by John Rose equals to "code > on bootclasspath", or in other words "core library code". > Traditionally there's been a lot of privilege checks in the JDK in the > form of "x.getClass().getClassLoader() == null", and it's just the same > here. > >> I'd also like to know what tests needed to be run to catch this. Maybe >> we need to add some jsr292 tests to JPRT? >> > With regards to adding JSR 292 tests to JPRT, I'm open to discussions. > We'd need more input from John and Christian. > > Thanks, > Kris > >> Thanks, >> David >> >>> It's causing a lot of failures in nightlies, so I'd like to get it >>> reviewed quickly and push it ASAP. >>> >>> Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 >>> (There's no public bug for this yet. The description is copied below.) >>> >>> Bug to cover recent nightly failures with: >>> >>> # To suppress the following error report, specify this argument >>> # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >>> (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, >>> tid=2731850608 >>> # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic >>> || resolved_method->is_compiled_lambda_form()) failed: linkMethod must >>> return one of these >>> # >>> # JRE version: Java(TM) SE Runtime Environment (8.0) (build >>> 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) >>> # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, >>> sharing linux-x86 ) >>> # Core dump written. Default location: XXX/core or core.7993 >>> # >>> # An error report file with more information is saved as: >>> # XXX/hs_err_pid7993.log >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://bugreport.sun.com/bugreport/crash.jsp >>> # >>> >>> This assertion is caused by a predicate on code privilege in >>> ClassFileParser::AnnotationCollector::annotation_index(): >>> >>> bool privileged = false; >>> if (loader_data->is_the_null_class_loader_data()) { >>> // Privileged code can use all annotations. Other code silently drops >>> some. >>> privileged = true; >>> } >>> >>> The problematic code was introduced in the @Contended change, >>> JDK-8003985: Support @Contended Annotation - JEP 142 >>> It didn't take into account that, with recent NPG changes for 292, every >>> anonymous class would have a dedicated ClassLoaderData which is not the >>> null_CLD, so the condition for privileged code was not complete. >>> >>> The way how this code triggers the assertion far away goes like this: >>> >>> (1) The new MethodHandle implementation for 292 via LambdaForm uses >>> anonymous classes to represent "compiled lambda forms". >>> (2) The sole method in compiled lambda forms is marked with three >>> special marker annotations: @Hidden, @Compiled and @ForceInline. >>> (3) There's special handling in the VM to recognized these annotations >>> while parsing the class file; but these annotations are handled >>> specially only when the class is privileged, otherwise the special >>> handling for them is ignored silently. >>> (4) That information is later used to tell if a Method is a compiled >>> lambda form. >>> >>> This bug introduced an incomplete predicate for code privilege in (3), >>> silently missed the special handling, and then triggered an assertion in >>> (4). >>> >>> The fix is to treat all anonymous classes as privileged code. This is >>> assumed to be safe in an internal discussion thread. >>> >>> --- a/src/share/vm/classfile/classFileParser.cpp >>> +++ b/src/share/vm/classfile/classFileParser.cpp >>> @@ -1802,11 +1802,9 @@ >>> ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* >>> loader_data, >>> Symbol* name) { >>> vmSymbols::SID sid = vmSymbols::find_sid(name); >>> - bool privileged = false; >>> - if (loader_data->is_the_null_class_loader_data()) { >>> - // Privileged code can use all annotations. Other code silently drops >>> some. >>> - privileged = true; >>> - } >>> + // Privileged code can use all annotations. Other code silently drops >>> some. >>> + bool privileged = loader_data->is_the_null_class_loader_data() || >>> + loader_data->is_anonymous(); >>> switch (sid) { >>> case >>> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >>> if (_location != _in_method) break; // only allow for methods >>> >>> Thanks, >>> Kris > From krystal.mo at oracle.com Thu Jan 24 01:39:09 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 17:39:09 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <51010092.8090509@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <5100FA98.8040806@oracle.com> <51010092.8090509@oracle.com> Message-ID: <5101013D.3060406@oracle.com> Thank you, David. - Kris On 01/24/2013 05:36 PM, David Holmes wrote: > On 24/01/2013 7:10 PM, Krystal Mo wrote: >> David, >> >> Thanks for the review. Comments inline: >> >> On 01/24/2013 04:53 PM, David Holmes wrote: >>> Hi Kris, >>> >>> On 24/01/2013 6:06 PM, Krystal Mo wrote: >>>> Hi all, >>>> >>>> Could anyone review this patch, please? >>> >>> Based on your description this patch seems to address the immediate >>> problem. >>> >> Yes. But that "immediate problem" is causing a lot of JSR 292 test >> failures, and we got a "nogo" for hs25-b16 PIT, so it's urgent to at >> least get the immediate problem fixed. > > Understood - you can consider this Reviewed. > > Thanks, > David > ------ > >> There's plans to add some jtreg tests to exercise this bug specifically, >> in a separate RFE. >> >>> My concern is whether this whole "privileged" notion that @Contended >>> introduced is actually valid? Is this how the constraint that >>> @Contended can only be applied to classes on the bootclasspath was >>> implemented? >>> >> >> Yes, the predicate in this bug is how @Contended only works for code on >> BCP. >> The notion of "privileged code" mentioned by John Rose equals to "code >> on bootclasspath", or in other words "core library code". >> Traditionally there's been a lot of privilege checks in the JDK in the >> form of "x.getClass().getClassLoader() == null", and it's just the same >> here. >> >>> I'd also like to know what tests needed to be run to catch this. Maybe >>> we need to add some jsr292 tests to JPRT? >>> >> With regards to adding JSR 292 tests to JPRT, I'm open to discussions. >> We'd need more input from John and Christian. >> >> Thanks, >> Kris >> >>> Thanks, >>> David >>> >>>> It's causing a lot of failures in nightlies, so I'd like to get it >>>> reviewed quickly and push it ASAP. >>>> >>>> Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 >>>> (There's no public bug for this yet. The description is copied below.) >>>> >>>> Bug to cover recent nightly failures with: >>>> >>>> # To suppress the following error report, specify this argument >>>> # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # Internal Error >>>> (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, >>>> tid=2731850608 >>>> # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic >>>> || resolved_method->is_compiled_lambda_form()) failed: linkMethod must >>>> return one of these >>>> # >>>> # JRE version: Java(TM) SE Runtime Environment (8.0) (build >>>> 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) >>>> # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled >>>> mode, >>>> sharing linux-x86 ) >>>> # Core dump written. Default location: XXX/core or core.7993 >>>> # >>>> # An error report file with more information is saved as: >>>> # XXX/hs_err_pid7993.log >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>> # >>>> >>>> This assertion is caused by a predicate on code privilege in >>>> ClassFileParser::AnnotationCollector::annotation_index(): >>>> >>>> bool privileged = false; >>>> if (loader_data->is_the_null_class_loader_data()) { >>>> // Privileged code can use all annotations. Other code silently drops >>>> some. >>>> privileged = true; >>>> } >>>> >>>> The problematic code was introduced in the @Contended change, >>>> JDK-8003985: Support @Contended Annotation - JEP 142 >>>> It didn't take into account that, with recent NPG changes for 292, >>>> every >>>> anonymous class would have a dedicated ClassLoaderData which is not >>>> the >>>> null_CLD, so the condition for privileged code was not complete. >>>> >>>> The way how this code triggers the assertion far away goes like this: >>>> >>>> (1) The new MethodHandle implementation for 292 via LambdaForm uses >>>> anonymous classes to represent "compiled lambda forms". >>>> (2) The sole method in compiled lambda forms is marked with three >>>> special marker annotations: @Hidden, @Compiled and @ForceInline. >>>> (3) There's special handling in the VM to recognized these annotations >>>> while parsing the class file; but these annotations are handled >>>> specially only when the class is privileged, otherwise the special >>>> handling for them is ignored silently. >>>> (4) That information is later used to tell if a Method is a compiled >>>> lambda form. >>>> >>>> This bug introduced an incomplete predicate for code privilege in (3), >>>> silently missed the special handling, and then triggered an >>>> assertion in >>>> (4). >>>> >>>> The fix is to treat all anonymous classes as privileged code. This is >>>> assumed to be safe in an internal discussion thread. >>>> >>>> --- a/src/share/vm/classfile/classFileParser.cpp >>>> +++ b/src/share/vm/classfile/classFileParser.cpp >>>> @@ -1802,11 +1802,9 @@ >>>> ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* >>>> >>>> loader_data, >>>> Symbol* name) { >>>> vmSymbols::SID sid = vmSymbols::find_sid(name); >>>> - bool privileged = false; >>>> - if (loader_data->is_the_null_class_loader_data()) { >>>> - // Privileged code can use all annotations. Other code silently >>>> drops >>>> some. >>>> - privileged = true; >>>> - } >>>> + // Privileged code can use all annotations. Other code silently >>>> drops >>>> some. >>>> + bool privileged = loader_data->is_the_null_class_loader_data() || >>>> + loader_data->is_anonymous(); >>>> switch (sid) { >>>> case >>>> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >>>> >>>> if (_location != _in_method) break; // only allow for methods >>>> >>>> Thanks, >>>> Kris >> From aleksey.shipilev at oracle.com Thu Jan 24 01:47:01 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Jan 2013 13:47:01 +0400 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100FFDF.5060507@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <5100F8DD.2070500@oracle.com> <5100FFDF.5060507@oracle.com> Message-ID: <51010315.2010708@oracle.com> On 01/24/2013 01:33 PM, David Holmes wrote: >>> My concern is whether this whole "privileged" notion that @Contended >>> introduced is actually valid? Is this how the constraint that @Contended >>> can only be applied to classes on the bootclasspath was implemented? >> The current consensus is that sun.misc.* members should be >> unaccessible/noop-ed for unprivileged classes. This applies as the >> general rule, and some annotations can have the exception with the VM >> flag (-XX:-RestrictContended in this case). > > It's not the policy I was questioning but the implementation. Given all > the different notions of "privilege" that already exist this seems > somewhat adhoc and slightly crude. But that is with hindsight. Oh yes, I can relate to this. However, this was viewed by most of the reviewers as appropriate idiomatic form for VM code. -Aleksey. From coleen.phillimore at oracle.com Thu Jan 24 06:09:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 09:09:06 -0500 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100F68E.8090509@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> Message-ID: <51014082.9040400@oracle.com> This change looks good to me also. Hopefully you've already pushed it. On 1/24/2013 3:53 AM, David Holmes wrote: > Hi Kris, > > On 24/01/2013 6:06 PM, Krystal Mo wrote: >> Hi all, >> >> Could anyone review this patch, please? > > Based on your description this patch seems to address the immediate > problem. > > My concern is whether this whole "privileged" notion that @Contended > introduced is actually valid? Is this how the constraint that > @Contended can only be applied to classes on the bootclasspath was > implemented? > > I'd also like to know what tests needed to be run to catch this. Maybe > we need to add some jsr292 tests to JPRT? Yes and some SA tests too, since it's very easy to break the SA (rest of comment deleted). Coleen > > Thanks, > David > >> It's causing a lot of failures in nightlies, so I'd like to get it >> reviewed quickly and push it ASAP. >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 >> (There's no public bug for this yet. The description is copied below.) >> >> Bug to cover recent nightly failures with: >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, >> tid=2731850608 >> # assert(resolved_method->intrinsic_id() == vmIntrinsics::_invokeBasic >> || resolved_method->is_compiled_lambda_form()) failed: linkMethod must >> return one of these >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0) (build >> 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) >> # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled mode, >> sharing linux-x86 ) >> # Core dump written. Default location: XXX/core or core.7993 >> # >> # An error report file with more information is saved as: >> # XXX/hs_err_pid7993.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> >> This assertion is caused by a predicate on code privilege in >> ClassFileParser::AnnotationCollector::annotation_index(): >> >> bool privileged = false; >> if (loader_data->is_the_null_class_loader_data()) { >> // Privileged code can use all annotations. Other code silently drops >> some. >> privileged = true; >> } >> >> The problematic code was introduced in the @Contended change, >> JDK-8003985: Support @Contended Annotation - JEP 142 >> It didn't take into account that, with recent NPG changes for 292, every >> anonymous class would have a dedicated ClassLoaderData which is not the >> null_CLD, so the condition for privileged code was not complete. >> >> The way how this code triggers the assertion far away goes like this: >> >> (1) The new MethodHandle implementation for 292 via LambdaForm uses >> anonymous classes to represent "compiled lambda forms". >> (2) The sole method in compiled lambda forms is marked with three >> special marker annotations: @Hidden, @Compiled and @ForceInline. >> (3) There's special handling in the VM to recognized these annotations >> while parsing the class file; but these annotations are handled >> specially only when the class is privileged, otherwise the special >> handling for them is ignored silently. >> (4) That information is later used to tell if a Method is a compiled >> lambda form. >> >> This bug introduced an incomplete predicate for code privilege in (3), >> silently missed the special handling, and then triggered an assertion in >> (4). >> >> The fix is to treat all anonymous classes as privileged code. This is >> assumed to be safe in an internal discussion thread. >> >> --- a/src/share/vm/classfile/classFileParser.cpp >> +++ b/src/share/vm/classfile/classFileParser.cpp >> @@ -1802,11 +1802,9 @@ >> ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* >> loader_data, >> Symbol* name) { >> vmSymbols::SID sid = vmSymbols::find_sid(name); >> - bool privileged = false; >> - if (loader_data->is_the_null_class_loader_data()) { >> - // Privileged code can use all annotations. Other code silently drops >> some. >> - privileged = true; >> - } >> + // Privileged code can use all annotations. Other code silently drops >> some. >> + bool privileged = loader_data->is_the_null_class_loader_data() || >> + loader_data->is_anonymous(); >> switch (sid) { >> case >> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >> if (_location != _in_method) break; // only allow for methods >> >> Thanks, >> Kris From nils.loodin at oracle.com Thu Jan 24 06:22:01 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 24 Jan 2013 15:22:01 +0100 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <51014389.6020601@oracle.com> vote: yes Nils Loodin On 01/22/2013 07:43 PM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was due > to a mistake on my side. He was definitely a large contributor to that > fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From zhengyu.gu at oracle.com Thu Jan 24 06:36:39 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 24 Jan 2013 09:36:39 -0500 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: <51009D57.20307@oracle.com> References: <50F992E1.6050704@oracle.com> <50FFFB78.50504@oracle.com> <51009D57.20307@oracle.com> Message-ID: <510146F7.3070901@oracle.com> I am not sure. CC-ed Bill from deployment. Bill, could you please shed some light on status of Kernel VM on JDK side? Has it already been removed? Thanks, -Zhengyu On 1/23/2013 9:32 PM, David Holmes wrote: > Looks good to me. > > Once question: I can not find sun.jkernel.DownloadManager anywhere > (open or closed repos). Has this already been removed? > > David > > On 24/01/2013 1:02 AM, Zhengyu Gu wrote: >> I updated webrev, based on the comments from David, Chris and Karen, >> etc. >> >> Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.01/ >> >> I also filed JBS bug 8006691 >> (https://jbs.oracle.com/bugs/browse/JDK-8006691) to track the removal of >> is_kernel_vm field in jvm_version_info structure. >> >> Thanks, >> >> -Zhengyu >> >> On 1/18/2013 1:22 PM, Zhengyu Gu wrote: >>> Hi, >>> >>> This is a cleanup of kernel code, since it is already obsoleted - JDK7 >>> and JDK8 are no longer building kernel. >>> >>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8000692 >>> Webrev: http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ >>> >>> Tests: >>> - JPRT >>> - ute vm.quick.testlist on Linux x32. >>> >>> Thanks, >>> >>> -Zhengyu From krystal.mo at oracle.com Thu Jan 24 07:04:15 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 23:04:15 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <51014082.9040400@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <51014082.9040400@oracle.com> Message-ID: <51014D6F.7030707@oracle.com> Coleen, Thank you for the review. I listed you as a reviewer :-) I have pushed it to hotspot-comp already indeed, and I'm just about to sync hotspot-comp to hotspot-main. Thanks, Kris On 01/24/2013 10:09 PM, Coleen Phillimore wrote: > > This change looks good to me also. Hopefully you've already pushed it. > > On 1/24/2013 3:53 AM, David Holmes wrote: >> Hi Kris, >> >> On 24/01/2013 6:06 PM, Krystal Mo wrote: >>> Hi all, >>> >>> Could anyone review this patch, please? >> >> Based on your description this patch seems to address the immediate >> problem. >> >> My concern is whether this whole "privileged" notion that @Contended >> introduced is actually valid? Is this how the constraint that >> @Contended can only be applied to classes on the bootclasspath was >> implemented? >> >> I'd also like to know what tests needed to be run to catch this. >> Maybe we need to add some jsr292 tests to JPRT? > > Yes and some SA tests too, since it's very easy to break the SA (rest > of comment deleted). > > Coleen From alejandro.murillo at oracle.com Thu Jan 24 07:19:13 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 24 Jan 2013 08:19:13 -0700 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <51014D6F.7030707@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <51014082.9040400@oracle.com> <51014D6F.7030707@oracle.com> Message-ID: <510150F1.8010601@oracle.com> Sounds good Kris, please make sure this is indeed fixing the failures showing in nightly before you push to hs-main, not asking to wait for nightly, but to run those failing tests cheers Alejandro On 1/24/2013 8:04 AM, Krystal Mo wrote: > Coleen, > > Thank you for the review. I listed you as a reviewer :-) > I have pushed it to hotspot-comp already indeed, and I'm just about to > sync hotspot-comp to hotspot-main. > > Thanks, > Kris > > On 01/24/2013 10:09 PM, Coleen Phillimore wrote: >> >> This change looks good to me also. Hopefully you've already pushed >> it. >> >> On 1/24/2013 3:53 AM, David Holmes wrote: >>> Hi Kris, >>> >>> On 24/01/2013 6:06 PM, Krystal Mo wrote: >>>> Hi all, >>>> >>>> Could anyone review this patch, please? >>> >>> Based on your description this patch seems to address the immediate >>> problem. >>> >>> My concern is whether this whole "privileged" notion that @Contended >>> introduced is actually valid? Is this how the constraint that >>> @Contended can only be applied to classes on the bootclasspath was >>> implemented? >>> >>> I'd also like to know what tests needed to be run to catch this. >>> Maybe we need to add some jsr292 tests to JPRT? >> >> Yes and some SA tests too, since it's very easy to break the SA (rest >> of comment deleted). >> >> Coleen From krystal.mo at oracle.com Thu Jan 24 07:20:49 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 23:20:49 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <5100ED4F.5010805@oracle.com> References: <5100EB96.3030409@oracle.com> <5100ED4F.5010805@oracle.com> Message-ID: <51015151.2050301@oracle.com> Test results: JPRT passed jtreg java/lang/invoke basically passed; fails are due to javac timeouts jtreg compiler basically passed; fails are due to javac timeouts. The failing tests before fixing 8006758 now pass. UTE vm.jit.list passed - Kris On 01/24/2013 04:14 PM, Krystal Mo wrote: > The fix is being tested with (1) JPRT, (2) jtreg compiler and (3) > jtreg java/lang/invoke > > I'm seeing some javac compilation timeouts in (3), but the tests that > built fine are passing. > Will update on test results when all three tests finish. > > - Kris > > On 01/24/2013 04:06 PM, Krystal Mo wrote: >> Hi all, >> >> Could anyone review this patch, please? >> It's causing a lot of failures in nightlies, so I'd like to get it >> reviewed quickly and push it ASAP. >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006758/webrev.00/ >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8006758 >> (There's no public bug for this yet. The description is copied below.) >> >> Bug to cover recent nightly failures with: >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:99 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (XXX/hotspot/src/share/vm/interpreter/linkResolver.cpp:99), pid=7993, >> tid=2731850608 >> # assert(resolved_method->intrinsic_id() == >> vmIntrinsics::_invokeBasic || >> resolved_method->is_compiled_lambda_form()) failed: linkMethod must >> return one of these >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0) (build >> 1.8.0-internal-fastdebug-201301181518.amurillo.hs25-b16-jdk8-b74--b00) >> # Java VM: Java HotSpot(TM) Client VM (25.0-b16-fastdebug compiled >> mode, sharing linux-x86 ) >> # Core dump written. Default location: XXX/core or core.7993 >> # >> # An error report file with more information is saved as: >> # XXX/hs_err_pid7993.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> >> This assertion is caused by a predicate on code privilege in >> ClassFileParser::AnnotationCollector::annotation_index(): >> >> bool privileged = false; >> if (loader_data->is_the_null_class_loader_data()) { >> // Privileged code can use all annotations. Other code silently >> drops some. >> privileged = true; >> } >> >> The problematic code was introduced in the @Contended change, >> JDK-8003985: Support @Contended Annotation - JEP 142 >> It didn't take into account that, with recent NPG changes for 292, >> every anonymous class would have a dedicated ClassLoaderData which is >> not the null_CLD, so the condition for privileged code was not complete. >> >> The way how this code triggers the assertion far away goes like this: >> >> (1) The new MethodHandle implementation for 292 via LambdaForm uses >> anonymous classes to represent "compiled lambda forms". >> (2) The sole method in compiled lambda forms is marked with three >> special marker annotations: @Hidden, @Compiled and @ForceInline. >> (3) There's special handling in the VM to recognized these >> annotations while parsing the class file; but these annotations are >> handled specially only when the class is privileged, otherwise the >> special handling for them is ignored silently. >> (4) That information is later used to tell if a Method is a compiled >> lambda form. >> >> This bug introduced an incomplete predicate for code privilege in >> (3), silently missed the special handling, and then triggered an >> assertion in (4). >> >> The fix is to treat all anonymous classes as privileged code. This is >> assumed to be safe in an internal discussion thread. >> >> --- a/src/share/vm/classfile/classFileParser.cpp >> +++ b/src/share/vm/classfile/classFileParser.cpp >> @@ -1802,11 +1802,9 @@ >> ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* >> loader_data, >> Symbol* name) { >> vmSymbols::SID sid = vmSymbols::find_sid(name); >> - bool privileged = false; >> - if (loader_data->is_the_null_class_loader_data()) { >> - // Privileged code can use all annotations. Other code silently >> drops some. >> - privileged = true; >> - } >> + // Privileged code can use all annotations. Other code silently >> drops some. >> + bool privileged = loader_data->is_the_null_class_loader_data() || >> + loader_data->is_anonymous(); >> switch (sid) { >> case >> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >> if (_location != _in_method) break; // only allow for methods >> >> Thanks, >> Kris > From krystal.mo at oracle.com Thu Jan 24 07:22:39 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 23:22:39 +0800 Subject: Request for review (XS): JDK-8006758: LinkResolver assertion (caused by @Contended changes) In-Reply-To: <510150F1.8010601@oracle.com> References: <5100EB96.3030409@oracle.com> <5100F68E.8090509@oracle.com> <51014082.9040400@oracle.com> <51014D6F.7030707@oracle.com> <510150F1.8010601@oracle.com> Message-ID: <510151BF.2050607@oracle.com> On 01/24/2013 11:19 PM, Alejandro E Murillo wrote: > > Sounds good Kris, > please make sure this is indeed fixing the failures showing in nightly > before you push to hs-main, > not asking to wait for nightly, but to run those failing tests Thanks for the reminder, Alejandro. I have done so. The jtreg tests in compiler and java/lang/invoke that failed due to this bug now pass. Thanks, Kris > cheers > Alejandro > > On 1/24/2013 8:04 AM, Krystal Mo wrote: >> Coleen, >> >> Thank you for the review. I listed you as a reviewer :-) >> I have pushed it to hotspot-comp already indeed, and I'm just about >> to sync hotspot-comp to hotspot-main. >> >> Thanks, >> Kris >> >> On 01/24/2013 10:09 PM, Coleen Phillimore wrote: >>> >>> This change looks good to me also. Hopefully you've already >>> pushed it. >>> >>> On 1/24/2013 3:53 AM, David Holmes wrote: >>>> Hi Kris, >>>> >>>> On 24/01/2013 6:06 PM, Krystal Mo wrote: >>>>> Hi all, >>>>> >>>>> Could anyone review this patch, please? >>>> >>>> Based on your description this patch seems to address the immediate >>>> problem. >>>> >>>> My concern is whether this whole "privileged" notion that >>>> @Contended introduced is actually valid? Is this how the constraint >>>> that @Contended can only be applied to classes on the bootclasspath >>>> was implemented? >>>> >>>> I'd also like to know what tests needed to be run to catch this. >>>> Maybe we need to add some jsr292 tests to JPRT? >>> >>> Yes and some SA tests too, since it's very easy to break the SA >>> (rest of comment deleted). >>> >>> Coleen From jon.masamitsu at oracle.com Thu Jan 24 07:45:52 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 24 Jan 2013 07:45:52 -0800 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <51015730.4080700@oracle.com> vote: yes On 1/22/2013 10:43 AM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From jon.masamitsu at oracle.com Thu Jan 24 08:57:54 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 24 Jan 2013 16:57:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20130124165807.F281E4751F@hg.openjdk.java.net> Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d754ef7b9352 Merge From chris.plummer at oracle.com Thu Jan 24 09:48:56 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 24 Jan 2013 09:48:56 -0800 Subject: Code review request: JDK-8000692,Remove old KERNEL code In-Reply-To: References: Message-ID: <51017408.8050906@oracle.com> We stopped building kernel when minimalvm support was added. At the time it was only being built on Windows. As for sun.jkernel.DownloadManager, I see remnants of it in jdk/.hg/store/data, so it looks like it was deleted. install/src/windows still contains DownloadManager.c and DownloadManager.h. These should probably be removed. Chris On 1/24/13 7:46 AM, David Holmes wrote: > I am not sure. CC-ed Bill from deployment. > > Bill, could you please shed some light on status of Kernel VM on JDK > side? Has it already been removed? > > Thanks, > > -Zhengyu > > On 1/23/2013 9:32 PM, David Holmes wrote: >> >Looks good to me. >> > >> >Once question: I can not find sun.jkernel.DownloadManager anywhere >> >(open or closed repos). Has this already been removed? >> > >> >David >> > >> >On 24/01/2013 1:02 AM, Zhengyu Gu wrote: >>> >>I updated webrev, based on the comments from David, Chris and Karen, >>> >>etc. >>> >> >>> >>Webrev:http://cr.openjdk.java.net/~zgu/8000692/webrev.01/ >>> >> >>> >>I also filed JBS bug 8006691 >>> >>(https://jbs.oracle.com/bugs/browse/JDK-8006691) to track the removal of >>> >>is_kernel_vm field in jvm_version_info structure. >>> >> >>> >>Thanks, >>> >> >>> >>-Zhengyu >>> >> >>> >>On 1/18/2013 1:22 PM, Zhengyu Gu wrote: >>>> >>>Hi, >>>> >>> >>>> >>>This is a cleanup of kernel code, since it is already obsoleted - JDK7 >>>> >>>and JDK8 are no longer building kernel. >>>> >>> >>>> >>>JBS:https://jbs.oracle.com/bugs/browse/JDK-8000692 >>>> >>>Webrev:http://cr.openjdk.java.net/~zgu/8000692/webrev.00/ >>>> >>> >>>> >>>Tests: >>>> >>>- JPRT >>>> >>>- ute vm.quick.testlist on Linux x32. >>>> >>> >>>> >>>Thanks, >>>> >>> >>>> >>>-Zhengyu From john.cuthbertson at oracle.com Thu Jan 24 09:51:52 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 24 Jan 2013 09:51:52 -0800 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <510174B8.8050302@oracle.com> Vote: yes JohnC On 1/22/2013 10:43 AM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From fiteraup at yahoo.com Thu Jan 24 10:01:21 2013 From: fiteraup at yahoo.com (Fiterau Paul) Date: Thu, 24 Jan 2013 10:01:21 -0800 (PST) Subject: Explanation on the anatomy of a JNI call and return Message-ID: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> Hello guys. Sorry for the intrusion. Looked everywhere for this information, no luck. Browsed the code, very difficult to get an idea from it. 20 hours of search with no result. Also posted on StackOverflow, http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks, got no response. If someone could explain to me the evolution of the native and the java stack during a JNI call invocation, I'd be very appreciative. What I could find over the internet is this: http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html . But this is not Hotspot. Plus, I'm doubtful on whether the information is accurate, since, in a native to native call, you'd get a recurse in executeJava, the interpreter (like shown bellow) and I suspect the interpreter does not have the lightest of stack frames. * native stack: executeJava -> mNa -> executeJava -> mNb * Java stack: ?mNa -> mNb My question is, what's the anatomy of a java to native, native to native call and native to java in terms of stack frames. The purpose is, for a School project I have involving static analysis, where I should infer a very conservative upper bound for both the Java stack and the native stack. Right now there's a tool inferring the upper bound for the Java stack, but it doesn't take into account that some methods might already be compiled. I can use that measure in my inference. I'm especially interested in what would be the worst case with regards to stack consumption in a call chain. Let's say A calls B which calls C which calls D. ? Would it be more stack consuming if ?B, C and D were all native or it's more consuming if they are interleaved (one native one not).? From what tests I made, it seems that having all of them native does seem to yield the highest consumption. On the Native stack and on the java stack. Thanks for any input! And sorry for the not really dev oriented post.? Paul. From serguei.spitsyn at oracle.com Thu Jan 24 10:38:10 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2013 10:38:10 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <50FF29CA.9000009@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> Message-ID: <51017F92.6020803@oracle.com> I know everyone is overloaded this days, but... May I get a couple of reviews, please? Thanks, Serguei On 1/22/13 4:07 PM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > https://jbs.oracle.com/bugs/browse/JDK-8006542 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ > > Summary: > Need a support for invokedynamic entry kinds when new and old > constant pools are merged. > > Testing: > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > Asked the VM SQE team to develop new INDY tests for better coverage. > > > Thanks, > Serguei > > > From joseph.provino at oracle.com Thu Jan 24 10:38:54 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Thu, 24 Jan 2013 13:38:54 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS Message-ID: <51017FBE.1060106@oracle.com> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 It's a change to one file: arguments.cpp. thanks. joe From bob.vandette at oracle.com Thu Jan 24 10:45:09 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 24 Jan 2013 13:45:09 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51017FBE.1060106@oracle.com> References: <51017FBE.1060106@oracle.com> Message-ID: You claim to be defaulting to SerialGC but you don't set UseG1GC to false? If you build with INCLUDE_ALL_GCS=1, the G1 code will be available and be used. Bob. On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: > Webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 > > It's a change to one file: arguments.cpp. > > thanks. > > joe From joseph.provino at oracle.com Thu Jan 24 10:56:16 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Thu, 24 Jan 2013 13:56:16 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: References: <51017FBE.1060106@oracle.com> Message-ID: <510183D0.90007@oracle.com> On 1/24/2013 1:45 PM, Bob Vandette wrote: > You claim to be defaulting to SerialGC but you don't set UseG1GC to false? > > If you build with INCLUDE_ALL_GCS=1, the G1 code will be available and be used. Do I need a call to force_serial_gc() or maybe just FLAG_SET_DEFAULT(UseG1GC, false) joe > Bob. > > On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: > >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >> >> It's a change to one file: arguments.cpp. >> >> thanks. >> >> joe From John.Coomes at oracle.com Thu Jan 24 14:02:01 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 24 Jan 2013 14:02:01 -0800 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <20737.44889.654510.376626@oracle.com> Vote: yes -John From joseph.provino at oracle.com Thu Jan 24 14:04:07 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Thu, 24 Jan 2013 17:04:07 -0500 Subject: Request for review: 8003539 Minimal VM. VM don't react to -Dcom.sun.management and -XX:+ManagementServer Message-ID: <5101AFD7.2040604@oracle.com> This was reviewed awhile ago, but the changes got lost and weren't pushed. Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ From christian.thalinger at oracle.com Thu Jan 24 14:14:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Jan 2013 14:14:48 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <50FF29CA.9000009@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> Message-ID: On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > https://jbs.oracle.com/bugs/browse/JDK-8006542 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ src/share/vm/prims/jvmtiRedefineClasses.hpp: + // Support for constant pool merging (these routines are in alpha order): void append_entry(constantPoolHandle scratch_cp, int scratch_i, constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, int scratch_i, + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); int find_new_index(int old_index); Not really alpha order ;-) Otherwise this looks good (as far as I can tell). -- Chris > > Summary: > Need a support for invokedynamic entry kinds when new and old constant pools are merged. > > Testing: > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > Asked the VM SQE team to develop new INDY tests for better coverage. > > > Thanks, > Serguei > > > From serguei.spitsyn at oracle.com Thu Jan 24 14:56:36 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2013 14:56:36 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> Message-ID: <5101BC24.1020905@oracle.com> Christian, Thank you a lot for the review! Nice catch with the ordering. In fact, I tried to follow the order but missed that the find_new_index should go first. :) Thanks, Serguei On 1/24/13 2:14 PM, Christian Thalinger wrote: > On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://jbs.oracle.com/bugs/browse/JDK-8006542 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ > src/share/vm/prims/jvmtiRedefineClasses.hpp: > > + // Support for constant pool merging (these routines are in alpha order): > void append_entry(constantPoolHandle scratch_cp, int scratch_i, > constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); > + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, int scratch_i, > + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); > int find_new_index(int old_index); > > Not really alpha order ;-) > > Otherwise this looks good (as far as I can tell). > > -- Chris > >> Summary: >> Need a support for invokedynamic entry kinds when new and old constant pools are merged. >> >> Testing: >> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >> Asked the VM SQE team to develop new INDY tests for better coverage. >> >> >> Thanks, >> Serguei >> >> >> From david.holmes at oracle.com Thu Jan 24 15:43:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 09:43:54 +1000 Subject: Request for review: 8003539 Minimal VM. VM don't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <5101AFD7.2040604@oracle.com> References: <5101AFD7.2040604@oracle.com> Message-ID: <5101C73A.3070906@oracle.com> Hi Joe, On 25/01/2013 8:04 AM, Joe Provino wrote: > This was reviewed awhile ago, but the changes got lost and weren't pushed. > > Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ Original review thread is here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007235.html You can push with myself and Dmitry Samersoff as reviewers. (From email records it looks like JPRT was having a problem at the time you were ready to push this.) Thanks, David From joseph.provino at oracle.com Thu Jan 24 15:48:30 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Thu, 24 Jan 2013 18:48:30 -0500 Subject: Request for review: 8003539 Minimal VM. VM don't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <5101C73A.3070906@oracle.com> References: <5101AFD7.2040604@oracle.com> <5101C73A.3070906@oracle.com> Message-ID: <5101C84E.9000707@oracle.com> David, thanks! joe On 1/24/2013 6:43 PM, David Holmes wrote: > Hi Joe, > > On 25/01/2013 8:04 AM, Joe Provino wrote: >> This was reviewed awhile ago, but the changes got lost and weren't >> pushed. >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ > > Original review thread is here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007235.html > > > You can push with myself and Dmitry Samersoff as reviewers. > > (From email records it looks like JPRT was having a problem at the > time you were ready to push this.) > > Thanks, > David From coleen.phillimore at oracle.com Thu Jan 24 15:55:24 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 18:55:24 -0500 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5101BC24.1020905@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> Message-ID: <5101C9EC.6060608@oracle.com> Hi Serguei, Putting functions in alphabetical order seems silly, it's better to have utility functions directly above (or below) the function that calls them. I'd take out the comment. I have started looking at this code a bit. This function find_or_append_indirect_entry() should be used for the other indirect entries also, shouldn't it? The code looks familiar to the inside of the case statement to FieldRef, InterfaceRef and MethodRef. Also is boot_spec an indirect index too that has to be appended? 564 int boot_spec = scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); Thanks, Coleen On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: > Christian, > > > Thank you a lot for the review! > > Nice catch with the ordering. > In fact, I tried to follow the order but missed that the > find_new_index should go first. :) > > > Thanks, > Serguei > > > On 1/24/13 2:14 PM, Christian Thalinger wrote: >> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >> >>> Please, review the fix for: >>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >> src/share/vm/prims/jvmtiRedefineClasses.hpp: >> >> + // Support for constant pool merging (these routines are in alpha >> order): >> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >> + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, >> int scratch_i, >> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >> int find_new_index(int old_index); >> >> Not really alpha order ;-) >> >> Otherwise this looks good (as far as I can tell). >> >> -- Chris >> >>> Summary: >>> Need a support for invokedynamic entry kinds when new and old >>> constant pools are merged. >>> >>> Testing: >>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>> Asked the VM SQE team to develop new INDY tests for better coverage. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> > From alejandro.murillo at oracle.com Thu Jan 24 17:06:34 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 25 Jan 2013 01:06:34 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130125010643.F29CC4753E@hg.openjdk.java.net> Changeset: 998a24b491b0 Author: katleman Date: 2013-01-23 14:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/998a24b491b0 Added tag jdk7u14-b11 for changeset 06a41c6e29c2 ! .hgtags Changeset: 7b2efda91ffc Author: amurillo Date: 2013-01-24 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7b2efda91ffc Merge Changeset: e1bc0d406d3f Author: amurillo Date: 2013-01-24 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e1bc0d406d3f Added tag hs24-b31 for changeset 7b2efda91ffc ! .hgtags From krystal.mo at oracle.com Thu Jan 24 17:09:53 2013 From: krystal.mo at oracle.com (krystal.mo at oracle.com) Date: Fri, 25 Jan 2013 01:09:53 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130125011005.2C0564753F@hg.openjdk.java.net> Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/274a29bf5682 Merge From serguei.spitsyn at oracle.com Thu Jan 24 17:23:58 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2013 17:23:58 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5101C9EC.6060608@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> Message-ID: <5101DEAE.9000404@oracle.com> Hi Coleen, Thank you a lot for the review! On 1/24/13 3:55 PM, Coleen Phillimore wrote: > > Hi Serguei, > > Putting functions in alphabetical order seems silly, it's better to > have utility functions directly above (or below) the function that > calls them. I'd take out the comment. > > I have started looking at this code a bit. This function > find_or_append_indirect_entry() should be used for the other indirect > entries also, shouldn't it? The code looks familiar to the inside of > the case statement to FieldRef, InterfaceRef and MethodRef. You've got it right. Yes, I noticed it but did not want to mess with it until it is proven to work well. My plan was to fix it for the FieldRef, InterfaceRef and MethodRef in a next round of fixes. > > Also is boot_spec an indirect index too that has to be appended? > > 564 int boot_spec = > scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); This is a nice catch, will fix it. I thought, it is an index into the operands array, but it refers to a CONSTANT_MethodHandle element. Thanks, Serguei > > > Thanks, > Coleen > > On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >> Christian, >> >> >> Thank you a lot for the review! >> >> Nice catch with the ordering. >> In fact, I tried to follow the order but missed that the >> find_new_index should go first. :) >> >> >> Thanks, >> Serguei >> >> >> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>> >>>> Please, review the fix for: >>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>> >>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>> >>> + // Support for constant pool merging (these routines are in alpha >>> order): >>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>> + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, >>> int scratch_i, >>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>> int find_new_index(int old_index); >>> >>> Not really alpha order ;-) >>> >>> Otherwise this looks good (as far as I can tell). >>> >>> -- Chris >>> >>>> Summary: >>>> Need a support for invokedynamic entry kinds when new and old >>>> constant pools are merged. >>>> >>>> Testing: >>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>> Asked the VM SQE team to develop new INDY tests for better coverage. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >> > From perrywangsh at gmail.com Thu Jan 24 19:56:58 2013 From: perrywangsh at gmail.com (perry wang) Date: Fri, 25 Jan 2013 11:56:58 +0800 Subject: Explanation on the anatomy of a JNI call and return In-Reply-To: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> References: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> Message-ID: Hi, I try to answer your question according to my understanding with JVM specification 7. JVM keep a java stack for every java thread.This stack just a logic stack, a stack data structure defined by JVM implementation in memory. It has nothing with conventional runtime stack and heap. For native call, according to specification, you can directly use conventional stack that means you need not keep a stack structure in memory just like you call a general C method. Or you also can keep a logic stack data structure like for java method call for native method. This is depends JVM implementation. If I am wrong please other guys point out. Best Regards Peng On Fri, Jan 25, 2013 at 2:01 AM, Fiterau Paul wrote: > Hello guys. Sorry for the intrusion. Looked everywhere for this > information, no luck. Browsed the code, very difficult to get an idea from > it. 20 hours of search with no result. Also posted on StackOverflow, > http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks, > got no response. If someone could explain to me the evolution of the native > and the java stack during a JNI call invocation, I'd be very appreciative. > > What I could find over the internet is this: > http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html . > But this is not Hotspot. Plus, I'm doubtful on whether the information is > accurate, since, in a native to native call, you'd get a recurse in > executeJava, the interpreter (like shown bellow) and I suspect the > interpreter does not have the lightest of stack frames. > * native stack: executeJava -> mNa -> executeJava -> mNb > > * Java stack: mNa -> mNb > My question is, what's the anatomy of a java to native, native to native > call and native to java in terms of stack frames. The purpose is, for a > School project I have involving static analysis, where I should infer a > very conservative upper bound for both the Java stack and the native stack. > Right now there's a tool inferring the upper bound for the Java stack, but > it doesn't take into account that some methods might already be compiled. I > can use that measure in my inference. > > I'm especially interested in what would be the worst case with regards to > stack consumption in a call chain. Let's say A calls B which calls C which > calls D. > Would it be more stack consuming if B, C and D were all native or it's > more consuming if they are interleaved (one native one not). > From what tests I made, it seems that having all of them native does seem > to yield the highest consumption. On the Native stack and on the java stack. > > Thanks for any input! And sorry for the not really dev oriented post. > Paul. > From alejandro.murillo at oracle.com Thu Jan 24 20:08:28 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 25 Jan 2013 04:08:28 +0000 Subject: hg: hsx/hsx24/hotspot: 8006826: new hotspot build - hs24-b32 Message-ID: <20130125040834.770104754B@hg.openjdk.java.net> Changeset: 9a5777cc2847 Author: amurillo Date: 2013-01-24 11:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9a5777cc2847 8006826: new hotspot build - hs24-b32 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Thu Jan 24 21:28:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 15:28:26 +1000 Subject: Explanation on the anatomy of a JNI call and return In-Reply-To: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> References: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> Message-ID: <510217FA.5020401@oracle.com> On 25/01/2013 4:01 AM, Fiterau Paul wrote: > Hello guys. Sorry for the intrusion. Looked everywhere for this information, no luck. Browsed the code, very difficult to get an idea from it. 20 hours of search with no result. Also posted on StackOverflow, http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks, got no response. If someone could explain to me the evolution of the native and the java stack during a JNI call invocation, I'd be very appreciative. > > What I could find over the internet is this: http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html . But this is not Hotspot. Plus, I'm doubtful on whether the information is accurate, since, in a native to native call, you'd get a recurse in executeJava, the interpreter (like shown bellow) and I suspect the interpreter does not have the lightest of stack frames. > * native stack: executeJava -> mNa -> executeJava -> mNb > > * Java stack: mNa -> mNb > My question is, what's the anatomy of a java to native, native to native call and native to java in terms of stack frames. The purpose is, for a School project I have involving static analysis, where I should infer a very conservative upper bound for both the Java stack and the native stack. Right now there's a tool inferring the upper bound for the Java stack, but it doesn't take into account that some methods might already be compiled. I can use that measure in my inference. Not a simple question to answer as the details are very complex. The Java stack and the native stack are quite distinct and the details depend on whether you are running in interpreted code or compiled code. The Java stack is a logical stack of linked frames. The native stack frames need to be linked to the Java stack frames by some mechanism so that we can do stack walking. When you hit an invocation bytecode for a native method you call into a stub routine that prepares the Java stack and native stack so that the native method can be called directly. This involves marshalling arguments and performing thread-state transitions to mark the thread as executing native code. When the native method returns it marshalls any return value, cleans up the stack and returns to the point where you can execute the next bytecode. If your native method wants to call a Java method then it needs to use the JNI API, so that adds further marshalling etc and prepares the thread to recommence executing bytecodes. > I'm especially interested in what would be the worst case with regards to stack consumption in a call chain. Let's say A calls B which calls C which calls D. > Would it be more stack consuming if B, C and D were all native or it's more consuming if they are interleaved (one native one not). > From what tests I made, it seems that having all of them native does seem to yield the highest consumption. On the Native stack and on the java stack. I'm not completely clear on what you mean with the interleaving. Once you are in a native method then you can call another native method directly - not via JNI - so that yields minimum stack usage. Going back and forth between Java and native would consume the most stack as you have a lot of "management" code around the transitions. There is some information here: https://wikis.oracle.com/display/HotSpotInternals/Home but unfortunately most of the CallingSequence information is missing. David Holmes ------------ > Thanks for any input! And sorry for the not really dev oriented post. > Paul. From david.holmes at oracle.com Thu Jan 24 21:44:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 15:44:04 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: References: <51017FBE.1060106@oracle.com> Message-ID: <51021BA4.9000203@oracle.com> On 25/01/2013 4:45 AM, Bob Vandette wrote: > You claim to be defaulting to SerialGC but you don't set UseG1GC to false? The UNSUPPORTED_OPTION macro does that. But I don't see anything forcing use of serialGC. And force_serial_gc() should not be altered. > If you build with INCLUDE_ALL_GCS=1, the G1 code will be available and be used. Only on those platforms that support it. David > Bob. > > On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: > >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >> >> It's a change to one file: arguments.cpp. >> >> thanks. >> >> joe > From xieliang007 at gmail.com Thu Jan 24 23:42:55 2013 From: xieliang007 at gmail.com (liang xie) Date: Fri, 25 Jan 2013 15:42:55 +0800 Subject: Trivial patch about "Use CLOCK_MONOTONIC_RAW if available" Message-ID: Hi, I'm not familiar hotspot dev flow and i don't know how to make a webcr:) please feel free to move it to the correct list if wrong. "CLOCK_MONOTONIC_RAW" is available from 2.6.28+, it's a better choice while ntp slew happened againt CLOCK_MONOTONIC_RAW. This's important for some applications, e.g. zookeeper. Please see zookeeper--1616 for details. diff -r 8389681cd7b1 src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp Tue Nov 15 16:44:09 2011 -0800 +++ b/src/os/linux/vm/os_linux.cpp Fri Jan 25 15:14:55 2013 +0800 @@ -1444,7 +1444,11 @@ jlong os::javaTimeNanos() { if (Linux::supports_monotonic_clock()) { struct timespec tp; + #ifdef CLOCK_MONOTONIC_RAW + int status = Linux::clock_gettime(CLOCK_MONOTONIC_RAW, &tp); + #else int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp); + #endif assert(status == 0, "gettime error"); jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec); return result; From doug.simon at oracle.com Fri Jan 25 00:12:44 2013 From: doug.simon at oracle.com (Doug Simon @ Oracle) Date: Fri, 25 Jan 2013 09:12:44 +0100 Subject: Explanation on the anatomy of a JNI call and return In-Reply-To: <510217FA.5020401@oracle.com> References: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> <510217FA.5020401@oracle.com> Message-ID: Although it differs from HotSpot, looking *visually* at the stack frames in an execution of Maxine[1] may be instructive. You can use the Inspector to see the interleaving of native and Java stack frames by inspecting an execution of test.output.MixedFrames as follows: hg clone https://kenai.com/hg/maxine~maxine maxine cd maxine echo "JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home" >mx/env mxtool/mx build mxtool/mx image mxtool/mx inspect -cp com.oracle.max.tests/bin test.output.MixedFrames Once the Inspector GUI comes up, set a breakpoint in MixedFrames.testNative: Debug -> Break at method entry -> Method on class path, by name Class Name: MixedFrames Select Method Name: testNative Set Breakpoint Debug -> Resume (do this 3 times to get a deeper stack) You should now see something like this: https://dl.dropbox.com/u/3072238/Inspector.jpg You can then inspect any state of interest by clicking around in the GUI. If you have further questions specific to Maxine, please ask them on the Maxine mailing list (users at maxine.kenai.com). -Doug [1] https://wikis.oracle.com/display/MaxineVM/Home On Jan 25, 2013, at 6:28 AM, David Holmes wrote: > On 25/01/2013 4:01 AM, Fiterau Paul wrote: >> Hello guys. Sorry for the intrusion. Looked everywhere for this information, no luck. Browsed the code, very difficult to get an idea from it. 20 hours of search with no result. Also posted on StackOverflow, http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks, got no response. If someone could explain to me the evolution of the native and the java stack during a JNI call invocation, I'd be very appreciative. >> >> What I could find over the internet is this: http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html . But this is not Hotspot. Plus, I'm doubtful on whether the information is accurate, since, in a native to native call, you'd get a recurse in executeJava, the interpreter (like shown bellow) and I suspect the interpreter does not have the lightest of stack frames. >> * native stack: executeJava -> mNa -> executeJava -> mNb >> >> * Java stack: mNa -> mNb >> My question is, what's the anatomy of a java to native, native to native call and native to java in terms of stack frames. The purpose is, for a School project I have involving static analysis, where I should infer a very conservative upper bound for both the Java stack and the native stack. Right now there's a tool inferring the upper bound for the Java stack, but it doesn't take into account that some methods might already be compiled. I can use that measure in my inference. > > Not a simple question to answer as the details are very complex. > > The Java stack and the native stack are quite distinct and the details depend on whether you are running in interpreted code or compiled code. The Java stack is a logical stack of linked frames. The native stack frames need to be linked to the Java stack frames by some mechanism so that we can do stack walking. > > When you hit an invocation bytecode for a native method you call into a stub routine that prepares the Java stack and native stack so that the native method can be called directly. This involves marshalling arguments and performing thread-state transitions to mark the thread as executing native code. When the native method returns it marshalls any return value, cleans up the stack and returns to the point where you can execute the next bytecode. > > If your native method wants to call a Java method then it needs to use the JNI API, so that adds further marshalling etc and prepares the thread to recommence executing bytecodes. > >> I'm especially interested in what would be the worst case with regards to stack consumption in a call chain. Let's say A calls B which calls C which calls D. >> Would it be more stack consuming if B, C and D were all native or it's more consuming if they are interleaved (one native one not). >> From what tests I made, it seems that having all of them native does seem to yield the highest consumption. On the Native stack and on the java stack. > > I'm not completely clear on what you mean with the interleaving. Once you are in a native method then you can call another native method directly - not via JNI - so that yields minimum stack usage. Going back and forth between Java and native would consume the most stack as you have a lot of "management" code around the transitions. > > There is some information here: > > https://wikis.oracle.com/display/HotSpotInternals/Home > > but unfortunately most of the CallingSequence information is missing. > > David Holmes > ------------ > >> Thanks for any input! And sorry for the not really dev oriented post. >> Paul. From david.holmes at oracle.com Fri Jan 25 01:05:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 19:05:35 +1000 Subject: Trivial patch about "Use CLOCK_MONOTONIC_RAW if available" In-Reply-To: References: Message-ID: <51024ADF.3030907@oracle.com> Hi, On 25/01/2013 5:42 PM, liang xie wrote: > Hi, > > I'm not familiar hotspot dev flow and i don't know how to make a webcr:) > please feel free to move it to the correct list if wrong. This list is fine. It could have gone to hotspot-runtime-dev but broder coverage is fine for this. > "CLOCK_MONOTONIC_RAW" is available from 2.6.28+, it's a better choice while > ntp > slew happened againt CLOCK_MONOTONIC_RAW. This's important for some > applications, e.g. zookeeper. Please see zookeeper--1616 for details. > > > diff -r 8389681cd7b1 src/os/linux/vm/os_linux.cpp > --- a/src/os/linux/vm/os_linux.cpp Tue Nov 15 16:44:09 2011 -0800 > +++ b/src/os/linux/vm/os_linux.cpp Fri Jan 25 15:14:55 2013 +0800 > @@ -1444,7 +1444,11 @@ > jlong os::javaTimeNanos() { > if (Linux::supports_monotonic_clock()) { > struct timespec tp; > + #ifdef CLOCK_MONOTONIC_RAW > + int status = Linux::clock_gettime(CLOCK_MONOTONIC_RAW,&tp); > + #else > int status = Linux::clock_gettime(CLOCK_MONOTONIC,&tp); > + #endif > assert(status == 0, "gettime error"); > jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + > jlong(tp.tv_nsec); > return result; Unfortunately today our primary linux build platform is still at 2.6.27 so this would have to wait until we officially update that. But also we need to be able to run on earlier versions so this would have to involve a dynamic runtime check not a simple compile-time check. I've created 8006942 to track this. It will appear on bugs.sun.com in the next day or so. Thanks, David Holmes From fiteraup at yahoo.com Fri Jan 25 03:11:00 2013 From: fiteraup at yahoo.com (Fiterau Paul) Date: Fri, 25 Jan 2013 03:11:00 -0800 (PST) Subject: Explanation on the anatomy of a JNI call and return In-Reply-To: <510217FA.5020401@oracle.com> References: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> <510217FA.5020401@oracle.com> Message-ID: <1359112260.31998.YahooMailNeo@web125004.mail.ne1.yahoo.com> Thanks guys for all of your responses. They have all been helpful. I'll try Maxine out.I think I made one major mistake in my question. Confusing a native call with a call to an already compiled method. Let's say, we can have only compiled methods and interpreted methods with JIT no longer active. What would yield the worst stack consumption, in terms of a simple sequence call: a -> b -> c. Having b and c compiled, or having b compiled c interpreted.? >> Hello guys. Sorry for the intrusion. Looked everywhere for this information, no luck. Browsed the code, very difficult to get an idea from it. 20 hours of search >>with no result. Also posted on StackOverflow, http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks, got no response. If >>someone could explain to me the evolution of the native and the java stack during a JNI call invocation, I'd be very appreciative. >> >> What I could find over the internet is this: http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html . But this is not Hotspot. Plus, I'm doubtful >>on whether the information is accurate, since, in a native to native call, you'd get a recurse in executeJava, the interpreter (like shown bellow) and I suspect the >>interpreter does not have the lightest of stack frames. >> ? ?* native stack: executeJava ->? mNa ->? executeJava ->? mNb >> >> ? * Java stack:? mNa ->? mNb >> My question is, what's the anatomy of a java to native, native to native call and native to java in terms of stack frames. The purpose is, for a School project I >>have involving static analysis, where I should infer a very conservative upper bound for both the Java stack and the native stack. Right now there's a tool >>inferring the upper bound for the Java stack, but it doesn't take into account that some methods might already be compiled. I can use that measure in my >>inference. >Not a simple question to answer as the details are very complex. >The Java stack and the native stack are quite distinct and the details depend on whether you are running in interpreted code or compiled code. The Java stack is a >logical stack of linked frames. The native stack frames need to be linked to the Java stack frames by some mechanism so that we can do stack walking. >When you hit an invocation bytecode for a native method you call into a stub routine that prepares the Java stack and native stack so that the native method can >be called directly. This involves marshalling arguments and performing thread-state transitions to mark the thread as executing native code. When the native >method returns it marshalls any return value, cleans up the stack and returns to the point where you can execute the next bytecode. >If your native method wants to call a Java method then it needs to use the JNI API, so that adds further marshalling etc and prepares the thread to recommence >executing bytecodes. By this, do you mean there's a kindof like a transitional frame added, whenever a interpreted calls a compiled and vice versa. What I suspected originally is that, let's say we have a, b, c all interpreted methods. a calls b, which calls c. The stack would look like: java ? stack: a frame ? ? ? ? ? ? ? -> b frame ? ? ? ? ? ? ? ? ? ?-> c frame native stack: interpreter frame Where the interpreter executes (interprets) all the bytecodes of the methods. The tool my research is done on, only does stack size upper bound approximation considering this case and only for the java stack. The goal would be to get some sort of upper bound for both the native stack size and the java stack size considering the fact that some methods might already be compiled. As input information, you can use the java stack size measurements done presuming all methods are interpreted. If in the sequence a b c, b is already compiled, while a and c are interpreted: java ? stack: a frame ? ? ? ? ? ? ? -> transitional frame from b to c -> c frame ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?->? native stack: interpreter frame?-> transitional frame from a to b?-> b frame ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> interpreter frame ? ? ? ? ? ? ? ? ? ? I suspected that the recurse through the interpreter frame would be the main source of stack cost. Another source of cost would consist of the transition frames. If both b and c are compiled, then, in the article I posted, it was stated that detecting whether the a method is already compiled or not is done in the interpreter. By that, I deduce that, in the case both are compiled, you'd still need a recurse through the interpreter. java ? stack: a frame ? ? ? ? ? ? ? -> ? ? ? ? ? ? ? ? ? ? ? ? ?? native stack: interpreter frame?-> transitional frame from a to b?-> b frame ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> interpreter frame ? ? ? ? ? ? ? ? ? ?-> c frame Now, I'm not sure if this holds any water for Hotspot. Especially the last scenario. Analyzing statically to get an upper measurement is pretty much impossible, if you have an active JIT compiler. But presuming all compilation is done ahead of time (not what's done with Hotspot, I know), is the evolution similar to what I've mentioned above? Because if that's the case, then, the worst case scenario for the native stack size would be having all these interpreter frames. If transitional frames do exist between compiled methods and interpreted methods and interpreted and compiled, can there be an upper bound placed on them? For example, something like, a transitional stack frame from "a to b" consumes less on the stack than the stack frame "a". And is the recursing through the interpreter frames done like how I pictured?? >> I'm especially interested in what would be the worst case with regards to stack consumption in a call chain. Let's say A calls B which calls C which calls D. >> Would it be more stack consuming if? B, C and D were all native or it's more consuming if they are interleaved (one native one not). >>? From what tests I made, it seems that having all of them native does seem to yield the highest consumption. On the Native stack and on the java stack. >I'm not completely clear on what you mean with the interleaving. Once you are in a native method then you can call another native method directly - not via JNI - >so that yields minimum stack usage. Going back and forth between Java and native would consume the most stack as you have a lot of "management" code >around the transitions. I think I got JNI and compiled methods mixed up. But would interleaving between already compiled and interpreted method calls yield the same result? Higher maximum reached size if you have interleaving than if subsequent calls are all compiled: interpreted a calls already compiled b, which calls interpreted c? than interpreted a calls already compiled b, which calls already compiled c >There is some information here: >https://wikis.oracle.com/display/HotSpotInternals/Home >but unfortunately most of the CallingSequence information is missing. >David Holmes >------------ Yeah, I noticed that already. Information not completed there is exactly the information I was looking for.? Thanks loads for the responses so far. Feel a bit uncomfortable asking the gurus around here, but my efforts of digging through the code and Internet haven't been at all fruitful. Another problem is, the tool I'm supposed to be helping, I don't have access to it. So there's quite a bit of confusion with regards to requirements.? Paul. From nils.eliasson at oracle.com Fri Jan 25 07:34:44 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 25 Jan 2013 16:34:44 +0100 Subject: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <5102A614.3000803@oracle.com> Vote: yes //Nils Bengt Rutisson skrev 2013-01-22 19:43: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From nils.eliasson at oracle.com Fri Jan 25 07:35:11 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 25 Jan 2013 16:35:11 +0100 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <5102A62F.1070304@oracle.com> Vote: yes //Nils Bengt Rutisson skrev 2013-01-21 12:48: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From coleen.phillimore at oracle.com Fri Jan 25 08:02:51 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Jan 2013 11:02:51 -0500 Subject: CFV: New HSX Reviewer: Zhengyu Gu Message-ID: <5102ACAB.8020705@oracle.com> I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. Zhengyu is on his third year as a Committer on the HSX project. He is a key contributor to the Hotspot Runtime group. He has implemented Native Memory Tracking, an important new feature, the hs_err log decoding from within the VM, as well as various other runtime fixes for Windows. He has 36 commits to the Hotspot code base currently. Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two weekvoting period). Only current HSX project Reviewers [2] are eligible to vote on thisnomination. For Three-Vote Consensus voting instructions, see [3]. Regards, Coleen Phillimore [0]http://openjdk.java.net/census/#hsx [1]http://openjdk.java.net/bylaws#reviewer [2]http://openjdk.java.net/projects/#reviewer-vote [3]http://openjdk.java.net/bylaws#three-vote-consensus From daniel.daugherty at oracle.com Fri Jan 25 08:09:53 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2013 09:09:53 -0700 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <5102AE51.6050108@oracle.com> Vote: yes Dan On 1/25/13 9:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He is > a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes > for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From jon.masamitsu at oracle.com Fri Jan 25 08:16:07 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 25 Jan 2013 08:16:07 -0800 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <5102AFC7.2050905@oracle.com> Vote: yes On 1/25/2013 8:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He > is a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes > for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From karen.kinnear at oracle.com Fri Jan 25 08:21:02 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 25 Jan 2013 11:21:02 -0500 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <3E933232-C2DE-4F17-9819-8115C10877B5@oracle.com> Vote: yes Karen On Jan 25, 2013, at 11:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He is a key contributor to the Hotspot Runtime group. He has implemented Native Memory Tracking, an important new feature, the hs_err log decoding from within the VM, as well as various other runtime fixes for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From joseph.provino at oracle.com Fri Jan 25 08:25:00 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 25 Jan 2013 11:25:00 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51021BA4.9000203@oracle.com> References: <51017FBE.1060106@oracle.com> <51021BA4.9000203@oracle.com> Message-ID: <5102B1DC.4050409@oracle.com> With changes from Bob and David, here is a new webrev: http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 joe On 1/25/2013 12:44 AM, David Holmes wrote: > On 25/01/2013 4:45 AM, Bob Vandette wrote: >> You claim to be defaulting to SerialGC but you don't set UseG1GC to >> false? > > The UNSUPPORTED_OPTION macro does that. > > But I don't see anything forcing use of serialGC. And > force_serial_gc() should not be altered. > >> If you build with INCLUDE_ALL_GCS=1, the G1 code will be available >> and be used. > > Only on those platforms that support it. > > David > >> Bob. >> >> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >> >>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>> >>> It's a change to one file: arguments.cpp. >>> >>> thanks. >>> >>> joe >> From joseph.provino at oracle.com Fri Jan 25 08:28:09 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 25 Jan 2013 11:28:09 -0500 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list Message-ID: <5102B299.5020605@oracle.com> 2 ffiles changed. Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 joe From joseph.provino at oracle.com Fri Jan 25 08:33:48 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 25 Jan 2013 11:33:48 -0500 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so Message-ID: <5102B3EC.80305@oracle.com> Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 joe From vladimir.kozlov at oracle.com Fri Jan 25 08:38:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Jan 2013 08:38:54 -0800 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <5102B51E.9010401@oracle.com> Vote: yes On 1/25/13 8:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He is > a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes for > Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From eric.mccorkle at oracle.com Fri Jan 25 09:53:59 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 25 Jan 2013 12:53:59 -0500 Subject: MethodParameters class file format change Message-ID: <5102C6B7.5040108@oracle.com> I don't think anyone is using MethodParameters at this point, but I want to post this just to be sure. The latest version of the spec alters the class file format of MethodParameters attributes. The latest version can be found here: http://cr.openjdk.java.net/~abuckley/8misc.pdf I will be committing patches to tl and hsx which update hotspot and the langtools tools to reflect this change. However, this will take some time to propagate, and may affect anyone using this feature (most likely, to write tests). Apologies for any inconvenience, Eric From dean.long at oracle.com Fri Jan 25 10:05:20 2013 From: dean.long at oracle.com (Dean Long) Date: Fri, 25 Jan 2013 10:05:20 -0800 Subject: Explanation on the anatomy of a JNI call and return In-Reply-To: <1359112260.31998.YahooMailNeo@web125004.mail.ne1.yahoo.com> References: <1359050481.85695.YahooMailNeo@web125006.mail.ne1.yahoo.com> <510217FA.5020401@oracle.com> <1359112260.31998.YahooMailNeo@web125004.mail.ne1.yahoo.com> Message-ID: <5102C960.40805@oracle.com> You could try printing the generated assembly code and looking at how much the native stack is adjusted by. dl https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly On 1/25/2013 3:11 AM, Fiterau Paul wrote: > Thanks guys for all of your responses. They have all been helpful. I'll try Maxine out.I think I made one major mistake in my question. Confusing a native call with a call to an already compiled method. Let's say, we can have only compiled methods and interpreted methods with JIT no longer active. What would yield the worst stack consumption, in terms of a simple sequence call: a -> b -> c. Having b and c compiled, or having b compiled c interpreted. > >>> Hello guys. Sorry for the intrusion. Looked everywhere for this information, no luck. Browsed the code, very difficult to get an idea from it. 20 hours of search>>with no result. Also posted on StackOverflow, http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks, got no response. If>>someone could explain to me the evolution of the native and the java stack during a JNI call invocation, I'd be very appreciative. >>> >>> What I could find over the internet is this: http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html . But this is not Hotspot. Plus, I'm doubtful>>on whether the information is accurate, since, in a native to native call, you'd get a recurse in executeJava, the interpreter (like shown bellow) and I suspect the>>interpreter does not have the lightest of stack frames. >>> * native stack: executeJava -> mNa -> executeJava -> mNb >>> >>> * Java stack: mNa -> mNb >>> My question is, what's the anatomy of a java to native, native to native call and native to java in terms of stack frames. The purpose is, for a School project I>>have involving static analysis, where I should infer a very conservative upper bound for both the Java stack and the native stack. Right now there's a tool>>inferring the upper bound for the Java stack, but it doesn't take into account that some methods might already be compiled. I can use that measure in my>>inference. >> Not a simple question to answer as the details are very complex. >> The Java stack and the native stack are quite distinct and the details depend on whether you are running in interpreted code or compiled code. The Java stack is a>logical stack of linked frames. The native stack frames need to be linked to the Java stack frames by some mechanism so that we can do stack walking. >> When you hit an invocation bytecode for a native method you call into a stub routine that prepares the Java stack and native stack so that the native method can>be called directly. This involves marshalling arguments and performing thread-state transitions to mark the thread as executing native code. When the native>method returns it marshalls any return value, cleans up the stack and returns to the point where you can execute the next bytecode. >> If your native method wants to call a Java method then it needs to use the JNI API, so that adds further marshalling etc and prepares the thread to recommence>executing bytecodes. > By this, do you mean there's a kindof like a transitional frame added, whenever a interpreted calls a compiled and vice versa. What I suspected originally is that, let's say we have a, b, c all interpreted methods. a calls b, which calls c. > The stack would look like: > java stack: a frame -> b frame -> c frame > > native stack: interpreter frame > Where the interpreter executes (interprets) all the bytecodes of the methods. > The tool my research is done on, only does stack size upper bound approximation considering this case and only for the java stack. The goal would be to get some sort of upper bound for both the native stack size and the java stack size considering the fact that some methods might already be compiled. As input information, you can use the java stack size measurements done presuming all methods are interpreted. > > > If in the sequence a b c, b is already compiled, while a and c are interpreted: > java stack: a frame -> transitional frame from b to c -> c frame -> > native stack: interpreter frame -> transitional frame from a to b -> b frame -> interpreter frame > > I suspected that the recurse through the interpreter frame would be the main source of stack cost. Another source of cost would consist of the transition frames. > > If both b and c are compiled, then, in the article I posted, it was stated that detecting whether the a method is already compiled or not is done in the interpreter. By that, I deduce that, in the case both are compiled, you'd still need a recurse through the interpreter. > java stack: a frame -> > native stack: interpreter frame -> transitional frame from a to b -> b frame -> interpreter frame -> c frame > > Now, I'm not sure if this holds any water for Hotspot. Especially the last scenario. > Analyzing statically to get an upper measurement is pretty much impossible, if you have an active JIT compiler. But presuming all compilation is done ahead of time (not what's done with Hotspot, I know), is the evolution similar to what I've mentioned above? Because if that's the case, then, the worst case scenario for the native stack size would be having all these interpreter frames. > > If transitional frames do exist between compiled methods and interpreted methods and interpreted and compiled, can there be an upper bound placed on them? For example, something like, a transitional stack frame from "a to b" consumes less on the stack than the stack frame "a". And is the recursing through the interpreter frames done like how I pictured? > >>> I'm especially interested in what would be the worst case with regards to stack consumption in a call chain. Let's say A calls B which calls C which calls D. >>> Would it be more stack consuming if B, C and D were all native or it's more consuming if they are interleaved (one native one not). >>> From what tests I made, it seems that having all of them native does seem to yield the highest consumption. On the Native stack and on the java stack. >> I'm not completely clear on what you mean with the interleaving. Once you are in a native method then you can call another native method directly - not via JNI ->so that yields minimum stack usage. Going back and forth between Java and native would consume the most stack as you have a lot of "management" code>around the transitions. > I think I got JNI and compiled methods mixed up. But would interleaving between already compiled and interpreted method calls yield the same result? Higher maximum reached size if you have interleaving than if subsequent calls are all compiled: > interpreted a calls already compiled b, which calls interpreted c > than > interpreted a calls already compiled b, which calls already compiled c > >> There is some information here: >> https://wikis.oracle.com/display/HotSpotInternals/Home >> but unfortunately most of the CallingSequence information is missing. >> David Holmes >> ------------ > Yeah, I noticed that already. Information not completed there is exactly the information I was looking for. > Thanks loads for the responses so far. Feel a bit uncomfortable asking the gurus around here, but my efforts of digging through the code and Internet haven't been at all fruitful. Another problem is, the tool I'm supposed to be helping, I don't have access to it. So there's quite a bit of confusion with regards to requirements. > Paul. From rkennke at redhat.com Fri Jan 25 11:45:15 2013 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 25 Jan 2013 20:45:15 +0100 Subject: RFR: Some build fixes for gcc4.7 In-Reply-To: References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com> <1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com> <1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com> <50C7E843.9020006@oracle.com> <1355300366.1747.169.camel@mercury> <1357592366.3314.15.camel@mercury> Message-ID: <1359143115.12167.20.camel@mercury> > >>> > >>>> From my perspective, there are the following proposed changes not > >>> committed yet: > >>> > >>> 1. > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html > >>> > >>>> From that one, only the jdk part is missing: > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>> > >>> I think it's the only one with a bug-id even: > >>> 8003868: fix shark for latest HotSpot and LLVM > >>> > >>> 2. Then there is the library_call build fixes. (Which have also been > >>> proposed by Yasumasa Suenaga, which now got the bug id 8004898 and > >>> Christian is working on it.) > >>> > >>> Then I posted a bunch of others on hotspot-compiler-dev (maybe > >>> hotspot-dev would have been better?) > >>> > >>> 3. Fix OSR in Shark for non-empty incoming stack > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html > >>> > >>> This one got a little review by David Chase, for which I will send an > >>> updated webrev soon. I was hoping to get some more feedback though, or > >>> even a bug-id. > >>> > >>> 4. Implement deoptimization support in Shark > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html > >>> > >>> This one did not get any feedback yet, no bug-id either. > >>> > >>> 5. Fix volatile float field access in Shark > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html > >>> > >>> Same, no feedback, no bug-id. > >>> > >>> 6. Enable JSR292 support in Shark > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html > >>> > >>> Got some positive feedback from John Rose, but no bug id and no > >>> progress. > >>> > >>> Please let me know if I should do anything different in the future > >>> (different mailing list, different format, ..) Also, if it helps, I can > >>> group all those changes into one big change, I just thought that it is > >>> easier to review in logical chunks (otherwise the changes would > >>> interleave and it's difficult to say what belongs to what). > >> > >> Currently we have some problems with JPRT so I waiting for that to be resolved. But I will take care of all the above. > > > > Hi, > > > > Is there any progress on these issues? Maybe at least give it a Bug ID > > so it's not forgotten? > > Yes, and I'm sorry about that. Let me create some bugs right now. Thanks Christian for pushing all of those. However, I just noticed that the JDK part for my very first zero/shark related change is still not in the repos :-) http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ As far as I can see there is now way for me to push it (even though you approved it). Could you please push that as well, to make things complete? Best regards, Roman From alejandro.murillo at oracle.com Fri Jan 25 12:42:02 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 25 Jan 2013 20:42:02 +0000 Subject: hg: hsx/hsx25/hotspot: 25 new changesets Message-ID: <20130125204257.88D764757D@hg.openjdk.java.net> Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/617b18aadb33 Merge Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d754ef7b9352 Merge Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/274a29bf5682 Merge Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags From alejandro.murillo at oracle.com Fri Jan 25 13:29:23 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 25 Jan 2013 21:29:23 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130125212940.1836F4757E@hg.openjdk.java.net> Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Fri Jan 25 23:52:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 17:52:20 +1000 Subject: MethodParameters class file format change In-Reply-To: <5102C6B7.5040108@oracle.com> References: <5102C6B7.5040108@oracle.com> Message-ID: <51038B34.5060209@oracle.com> Eric, These situations are historically known as Flag Days and they require careful management. I don't know exactly what has to be done but the way to approach this is to modify the VM to be prepared to handle both the old format and the new. Then after it has reached TL/jdk&langtools update jdk/langtools to start using the new format. Then if needs be once everything is in sync you can remove the hotspot code that handles the old format. (I assume that both old and new format are new with regard class version 52?) That way nothing breaks. There must already be tests for this new feature else you would be pushing untested code, so you would break these tests while your changes sync up. David On 26/01/2013 3:53 AM, Eric McCorkle wrote: > I don't think anyone is using MethodParameters at this point, but I want > to post this just to be sure. > > The latest version of the spec alters the class file format of > MethodParameters attributes. > > The latest version can be found here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > I will be committing patches to tl and hsx which update hotspot and the > langtools tools to reflect this change. However, this will take some > time to propagate, and may affect anyone using this feature (most > likely, to write tests). > > Apologies for any inconvenience, > Eric From david.holmes at oracle.com Fri Jan 25 23:57:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 17:57:19 +1000 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so In-Reply-To: <5102B3EC.80305@oracle.com> References: <5102B3EC.80305@oracle.com> Message-ID: <51038C5F.8060902@oracle.com> On 26/01/2013 2:33 AM, Joe Provino wrote: > Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 The bug synopsis is confusing - seems to me it is the launcher your are changing not the VM. Do we have gprof on Solaris? Does this change fix or break other profiling tools ? I don't grok the actual changes but there is a typo in the bsd file: + # profiledminimal1 minimal1 __shark/profiled shark? :) David > > joe From david.holmes at oracle.com Sat Jan 26 04:36:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 22:36:40 +1000 Subject: MethodParameters class file format change In-Reply-To: <51039239.6020905@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> Message-ID: <5103CDD8.2020009@oracle.com> Hi Chris, On 26/01/2013 6:22 PM, Chris Hegarty wrote: > David, > > As you know, recently we have seen jdk changes coming in from the > hotspot integration forests, thus potentially avoiding a flag day. I'm > not saying that this is necessarily a good idea, but just wondering if > it is now something that we should reconsider, over the hefty process > you described below? That said, it would require the said engineer > observe the general engineering processes that are required to > integrated into both TL and the hotspot forests. There was a lengthy discussion on this twelve months ago. At the time JSR-292 was flagged as a special case and not intended as a long-term case. Until we have the testing resources, gatekeeping and integration resources and processes in place, this is not something that can become the norm. David ----- > -Chris. > > On 01/26/2013 07:52 AM, David Holmes wrote: >> Eric, >> >> These situations are historically known as Flag Days and they require >> careful management. >> >> I don't know exactly what has to be done but the way to approach this is >> to modify the VM to be prepared to handle both the old format and the >> new. Then after it has reached TL/jdk&langtools update jdk/langtools to >> start using the new format. Then if needs be once everything is in sync >> you can remove the hotspot code that handles the old format. (I assume >> that both old and new format are new with regard class version 52?) That >> way nothing breaks. >> >> There must already be tests for this new feature else you would be >> pushing untested code, so you would break these tests while your changes >> sync up. >> >> David >> >> On 26/01/2013 3:53 AM, Eric McCorkle wrote: >>> I don't think anyone is using MethodParameters at this point, but I want >>> to post this just to be sure. >>> >>> The latest version of the spec alters the class file format of >>> MethodParameters attributes. >>> >>> The latest version can be found here: >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>> I will be committing patches to tl and hsx which update hotspot and the >>> langtools tools to reflect this change. However, this will take some >>> time to propagate, and may affect anyone using this feature (most >>> likely, to write tests). >>> >>> Apologies for any inconvenience, >>> Eric From david.holmes at oracle.com Sat Jan 26 04:47:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 22:47:14 +1000 Subject: MethodParameters class file format change In-Reply-To: <5103CDD8.2020009@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> <5103CDD8.2020009@oracle.com> Message-ID: <5103D052.3050008@oracle.com> On 26/01/2013 10:36 PM, David Holmes wrote: > Hi Chris, > > On 26/01/2013 6:22 PM, Chris Hegarty wrote: >> David, >> >> As you know, recently we have seen jdk changes coming in from the >> hotspot integration forests, thus potentially avoiding a flag day. I'm >> not saying that this is necessarily a good idea, but just wondering if >> it is now something that we should reconsider, over the hefty process >> you described below? That said, it would require the said engineer >> observe the general engineering processes that are required to >> integrated into both TL and the hotspot forests. > > There was a lengthy discussion on this twelve months ago. At the time > JSR-292 was flagged as a special case and not intended as a long-term > case. Until we have the testing resources, gatekeeping and integration > resources and processes in place, this is not something that can become > the norm. To be clear I'm not saying this can't happen. I'm just saying that the right people need to ensure that all the necessary pieces are in place, and the procedures established before we actually start doing it on a regular basis. David > David > ----- > >> -Chris. >> >> On 01/26/2013 07:52 AM, David Holmes wrote: >>> Eric, >>> >>> These situations are historically known as Flag Days and they require >>> careful management. >>> >>> I don't know exactly what has to be done but the way to approach this is >>> to modify the VM to be prepared to handle both the old format and the >>> new. Then after it has reached TL/jdk&langtools update jdk/langtools to >>> start using the new format. Then if needs be once everything is in sync >>> you can remove the hotspot code that handles the old format. (I assume >>> that both old and new format are new with regard class version 52?) That >>> way nothing breaks. >>> >>> There must already be tests for this new feature else you would be >>> pushing untested code, so you would break these tests while your changes >>> sync up. >>> >>> David >>> >>> On 26/01/2013 3:53 AM, Eric McCorkle wrote: >>>> I don't think anyone is using MethodParameters at this point, but I >>>> want >>>> to post this just to be sure. >>>> >>>> The latest version of the spec alters the class file format of >>>> MethodParameters attributes. >>>> >>>> The latest version can be found here: >>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>> >>>> I will be committing patches to tl and hsx which update hotspot and the >>>> langtools tools to reflect this change. However, this will take some >>>> time to propagate, and may affect anyone using this feature (most >>>> likely, to write tests). >>>> >>>> Apologies for any inconvenience, >>>> Eric From chris.hegarty at oracle.com Sat Jan 26 00:22:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 26 Jan 2013 08:22:17 +0000 Subject: MethodParameters class file format change In-Reply-To: <51038B34.5060209@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> Message-ID: <51039239.6020905@oracle.com> David, As you know, recently we have seen jdk changes coming in from the hotspot integration forests, thus potentially avoiding a flag day. I'm not saying that this is necessarily a good idea, but just wondering if it is now something that we should reconsider, over the hefty process you described below? That said, it would require the said engineer observe the general engineering processes that are required to integrated into both TL and the hotspot forests. -Chris. On 01/26/2013 07:52 AM, David Holmes wrote: > Eric, > > These situations are historically known as Flag Days and they require > careful management. > > I don't know exactly what has to be done but the way to approach this is > to modify the VM to be prepared to handle both the old format and the > new. Then after it has reached TL/jdk&langtools update jdk/langtools to > start using the new format. Then if needs be once everything is in sync > you can remove the hotspot code that handles the old format. (I assume > that both old and new format are new with regard class version 52?) That > way nothing breaks. > > There must already be tests for this new feature else you would be > pushing untested code, so you would break these tests while your changes > sync up. > > David > > On 26/01/2013 3:53 AM, Eric McCorkle wrote: >> I don't think anyone is using MethodParameters at this point, but I want >> to post this just to be sure. >> >> The latest version of the spec alters the class file format of >> MethodParameters attributes. >> >> The latest version can be found here: >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> I will be committing patches to tl and hsx which update hotspot and the >> langtools tools to reflect this change. However, this will take some >> time to propagate, and may affect anyone using this feature (most >> likely, to write tests). >> >> Apologies for any inconvenience, >> Eric From chris.hegarty at oracle.com Sat Jan 26 04:50:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 26 Jan 2013 12:50:14 +0000 Subject: MethodParameters class file format change In-Reply-To: <5103D052.3050008@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> <5103CDD8.2020009@oracle.com> <5103D052.3050008@oracle.com> Message-ID: <3D20D90C-8420-4DC2-870F-46703233C04A@oracle.com> On 26 Jan 2013, at 12:47, David Holmes wrote: > On 26/01/2013 10:36 PM, David Holmes wrote: >> Hi Chris, >> >> On 26/01/2013 6:22 PM, Chris Hegarty wrote: >>> David, >>> >>> As you know, recently we have seen jdk changes coming in from the >>> hotspot integration forests, thus potentially avoiding a flag day. I'm >>> not saying that this is necessarily a good idea, but just wondering if >>> it is now something that we should reconsider, over the hefty process >>> you described below? That said, it would require the said engineer >>> observe the general engineering processes that are required to >>> integrated into both TL and the hotspot forests. >> >> There was a lengthy discussion on this twelve months ago. At the time >> JSR-292 was flagged as a special case and not intended as a long-term >> case. Until we have the testing resources, gatekeeping and integration >> resources and processes in place, this is not something that can become >> the norm. > > To be clear I'm not saying this can't happen. I'm just saying that the right people need to ensure that all the necessary pieces are in place, and the procedures established before we actually start doing it on a regular basis. Yes, I agree. -Chris > > David > >> David >> ----- >> >>> -Chris. >>> >>> On 01/26/2013 07:52 AM, David Holmes wrote: >>>> Eric, >>>> >>>> These situations are historically known as Flag Days and they require >>>> careful management. >>>> >>>> I don't know exactly what has to be done but the way to approach this is >>>> to modify the VM to be prepared to handle both the old format and the >>>> new. Then after it has reached TL/jdk&langtools update jdk/langtools to >>>> start using the new format. Then if needs be once everything is in sync >>>> you can remove the hotspot code that handles the old format. (I assume >>>> that both old and new format are new with regard class version 52?) That >>>> way nothing breaks. >>>> >>>> There must already be tests for this new feature else you would be >>>> pushing untested code, so you would break these tests while your changes >>>> sync up. >>>> >>>> David >>>> >>>> On 26/01/2013 3:53 AM, Eric McCorkle wrote: >>>>> I don't think anyone is using MethodParameters at this point, but I >>>>> want >>>>> to post this just to be sure. >>>>> >>>>> The latest version of the spec alters the class file format of >>>>> MethodParameters attributes. >>>>> >>>>> The latest version can be found here: >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>>> >>>>> I will be committing patches to tl and hsx which update hotspot and the >>>>> langtools tools to reflect this change. However, this will take some >>>>> time to propagate, and may affect anyone using this feature (most >>>>> likely, to write tests). >>>>> >>>>> Apologies for any inconvenience, >>>>> Eric From joseph.provino at oracle.com Sun Jan 27 06:28:14 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Sun, 27 Jan 2013 09:28:14 -0500 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so In-Reply-To: <51038C5F.8060902@oracle.com> References: <5102B3EC.80305@oracle.com> <51038C5F.8060902@oracle.com> Message-ID: <5105397E.5030203@oracle.com> On 1/26/2013 2:57 AM, David Holmes wrote: > On 26/01/2013 2:33 AM, Joe Provino wrote: >> Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 > > The bug synopsis is confusing - seems to me it is the launcher your > are changing not the VM. I agree. A better synopsis would be "Unable to link gamma launcher statically with the VM object files." > Do we have gprof on Solaris? Does this change fix or break other > profiling tools ? I think these are actually unrelated to the problem once the problem is stated correctly. > I don't grok the actual changes The problem is that if you attempt to build the gamma launcher statically with the VM object files by setting LINK_INTO=AOUT on the make command line, the launcher will get undefined symbols. The handling of LINK_INTO in launcher.make is incorrect. ifeq ($(LINK_INTO),AOUT) LAUNCHER.o = launcher.o $(JVM_OBJ_FILES) LIBS_LAUNCHER += $(STATIC_STDCXX) $(LIBS) else LAUNCHER.o = launcher.o LIBS_LAUNCHER += -l$(JVM) $(LIBS) endif launcher.o is undefined. That isn't a problem in itself because LAUNCHER.o is never used. This is the line that links the launcher: $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) $(LIBS_LAUNCHER) The simple fix is to add $(LAUNCHER.o): $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) $(LAUNCHER.o) $(LIBS_LAUNCHER) I also got rid of launcher.o since it's not used. I think to clean this up, I'd define LAUNCHER.o to be the launcher object files plus the JVM object files if LINK_INTO is AOUT and the launcher object files plus -ljvm otherwise. Then to link the launcher, I'd use $(LAUNCHER.o) $(LIBS). Should I do something like this or just the minimal fix? joe > but there is a typo in the bsd file: > > + # profiledminimal1 minimal1 __shark/profiled > > shark? :) fixed. > > David > >> >> joe From bengt.rutisson at oracle.com Sun Jan 27 13:11:01 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Sun, 27 Jan 2013 22:11:01 +0100 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <510597E5.9080902@oracle.com> Vote: yes On 1/25/13 5:02 PM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He is > a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes > for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From aleksey.shipilev at oracle.com Mon Jan 28 04:02:25 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 28 Jan 2013 16:02:25 +0400 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx Message-ID: <510668D1.5070002@oracle.com> Hi guys, This is the tiny correction it would be nice to have: http://cr.openjdk.java.net/~shade/8006997/ Negative values make no sense (and also can ruin the classloading with the fields overlapping each other), so it would better to be uintx. I would need a sponsor to push this. -Aleksey. From eric.mccorkle at oracle.com Mon Jan 28 06:42:39 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 28 Jan 2013 09:42:39 -0500 Subject: MethodParameters class file format change In-Reply-To: <51038B34.5060209@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> Message-ID: <51068E5F.6080102@oracle.com> On 01/26/13 02:52, David Holmes wrote: > There must already be tests for this new feature else you would be > pushing untested code, so you would break these tests while your changes > sync up. > Tests do exist, but they are presently disabled. The end-to-end tests were part of JDK-8004729, which was pushed before the M6 deadline for tl. However, they fail on SPARC without JDK-8006005, which was pushed to hsx, but didn't make it over to tl in time for M6. Additionally, Peter Jensen is working with me to develop a more comprehensive test suite. And lastly, the spec for MethodParameters is not yet finalized. Therefore, the end-to-end tests are presently disabled. There are tests in javac as well, but they are being updated as part of the langtools patch. From eric.mccorkle at oracle.com Mon Jan 28 11:42:38 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 28 Jan 2013 14:42:38 -0500 Subject: Review request for JDK-8006949: Update hotspot for MethodParameters format change Message-ID: <5106D4AE.9050200@oracle.com> Hello, Please review this patch, which updates hotspot in accordance with changes to the class file format of MethodParameters attributes. The latest spec version is here: http://cr.openjdk.java.net/~abuckley/8misc.pdf Any questions regarding the format change or the spec should be directed to Alex Buckley, the spec owner. The webrev is here: http://cr.openjdk.java.net/~emc/8006949/ The enhancement request is here: http://bugs.sun.com/view_bug.do?bug_id=8006949 The following CCC has been filed for this change: http://ccc.us.oracle.com/8006948 The end-to-end tests for MethodParameters are presently disabled; however, I have run the end-to-end tests with this patch, as well as the companion patch for JDK-8006948, and seen no failures. I am presently running testlist and JPRT jobs; however, given the extremely small nature of the changeset, I do not anticipate seeing any failures. Thanks, Eric From john.r.rose at oracle.com Mon Jan 28 11:59:15 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Jan 2013 11:59:15 -0800 Subject: MethodParameters class file format change In-Reply-To: <3D20D90C-8420-4DC2-870F-46703233C04A@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> <5103CDD8.2020009@oracle.com> <5103D052.3050008@oracle.com> <3D20D90C-8420-4DC2-870F-46703233C04A@oracle.com> Message-ID: On Jan 26, 2013, at 4:50 AM, Chris Hegarty wrote: >> To be clear I'm not saying this can't happen. I'm just saying that the right people need to ensure that all the necessary pieces are in place, and the procedures established before we actually start doing it on a regular basis. > > Yes, I agree. I agree vigorously with David about the high risk and cost of flag days. If your job as an individual engineer is complicated 10x by the cost of avoiding a flag day, it is still well worth the effort. I will say this: It shouldn't happen very often at all. The last 292 flag day involved 10,000's of LOC, replacing an old implementation by a new one. It was also very expensive and difficult and distracting to manage. It required 10's of engineers throughout the engineering pipeline to pay special attention, for days. It caused semi-expected regressions and hiccups in the backport processes. It required SQE to know when *not* to pay attention to certain regressions. This is so totally not worth it for almost all changes! One engineer with a little cleverness can figure out a way to make the micro-version matrix pass nightly tests. (That's at least three of {jdk0,jdk1}x{jvm0,jvm1}.) It makes ugly code, but that is far preferable to ugly process adventures. Mark the code as "FIXME: clean up after ..." and then trust that, if it's important, it will get cleaned up. The 292-scoped JDK changes are a special case also, which has been discussed at length elsewhere. It requires a lot of groundwork laying, and a significant "teething process" until everybody knows that stuff is coming from that direction. It is not a cut-and-paste-your-own type of process. Having been this this micro-version matrix many times with 292, I can point out some useful tricks for making things work out; just ask. (1-1 mail probably works best for that sort of question.) ? John P.S. This is mostly FTR. For the problem at hand, Eric tells me he already thought of a suitable "trick". Yay! From coleen.phillimore at oracle.com Mon Jan 28 13:47:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Jan 2013 16:47:17 -0500 Subject: Review request for JDK-8006949: Update hotspot for MethodParameters format change In-Reply-To: <5106D4AE.9050200@oracle.com> References: <5106D4AE.9050200@oracle.com> Message-ID: <5106F1E5.7020808@oracle.com> This is nice change to have the flags smaller. The method parameter tests are disabled and method parameters aren't found in the JDK classfiles yet, so this will not fail with a version of the JDK that has the flags as u4, right? Thanks, Coleen On 01/28/2013 02:42 PM, Eric McCorkle wrote: > Hello, > > Please review this patch, which updates hotspot in accordance with > changes to the class file format of MethodParameters attributes. > > The latest spec version is here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > Any questions regarding the format change or the spec should be directed > to Alex Buckley, the spec owner. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8006949/ > > The enhancement request is here: > http://bugs.sun.com/view_bug.do?bug_id=8006949 > > The following CCC has been filed for this change: > http://ccc.us.oracle.com/8006948 > > > The end-to-end tests for MethodParameters are presently disabled; > however, I have run the end-to-end tests with this patch, as well as the > companion patch for JDK-8006948, and seen no failures. > > I am presently running testlist and JPRT jobs; however, given the > extremely small nature of the changeset, I do not anticipate seeing any > failures. > > Thanks, > Eric From serguei.spitsyn at oracle.com Mon Jan 28 14:18:03 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 14:18:03 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5101DEAE.9000404@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> Message-ID: <5106F91B.4040900@oracle.com> Hi Coleen, This is a new webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ As you pointed out, the InvokeDynamic entry support should also do cross-checks with the bootstrap method operands (arguments) and recursive extra appends if necessary. I've filed a separate bug to track this issue: https://jbs.oracle.com/bugs/browse/JDK-8007037 I want to separate this issue to be able to integrate what I have now and concentrate on the rest later. The VM SQE team developed new INDY tests that cover the RedefineClasses issues. I hope to adopt and use new tests soon to make sure most of the issues are actually resolved. Thanks, Serguei On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > Thank you a lot for the review! > > On 1/24/13 3:55 PM, Coleen Phillimore wrote: >> >> Hi Serguei, >> >> Putting functions in alphabetical order seems silly, it's better to >> have utility functions directly above (or below) the function that >> calls them. I'd take out the comment. >> >> I have started looking at this code a bit. This function >> find_or_append_indirect_entry() should be used for the other indirect >> entries also, shouldn't it? The code looks familiar to the inside of >> the case statement to FieldRef, InterfaceRef and MethodRef. > > You've got it right. > Yes, I noticed it but did not want to mess with it until it is proven > to work well. > My plan was to fix it for the FieldRef, InterfaceRef and MethodRef in > a next round of fixes. > >> >> Also is boot_spec an indirect index too that has to be appended? >> >> 564 int boot_spec = >> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); > > This is a nice catch, will fix it. > I thought, it is an index into the operands array, but it refers to a > CONSTANT_MethodHandle element. > > > Thanks, > Serguei > > >> >> >> Thanks, >> Coleen >> >> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>> Christian, >>> >>> >>> Thank you a lot for the review! >>> >>> Nice catch with the ordering. >>> In fact, I tried to follow the order but missed that the >>> find_new_index should go first. :) >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>>> Please, review the fix for: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>> >>>> + // Support for constant pool merging (these routines are in >>>> alpha order): >>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>> + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, >>>> int scratch_i, >>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>> int find_new_index(int old_index); >>>> >>>> Not really alpha order ;-) >>>> >>>> Otherwise this looks good (as far as I can tell). >>>> >>>> -- Chris >>>> >>>>> Summary: >>>>> Need a support for invokedynamic entry kinds when new and old >>>>> constant pools are merged. >>>>> >>>>> Testing: >>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>> Asked the VM SQE team to develop new INDY tests for better >>>>> coverage. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Mon Jan 28 14:33:43 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 14:33:43 -0800 Subject: Review Request (XS) 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <5106FCC7.4050201@oracle.com> Please, review the fix for (it was already reviewed by Christian): https://jbs.oracle.com/bugs/browse/JDK-8006546 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006546-JVMTI-JSR292.0 Summary: The copy_operands() does the same copy frrom dest cpool twice in two places. Instead, it must copy once from dest and once from source cpool. It would make it consistent with the comments. Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Thanks, Serguei From serguei.spitsyn at oracle.com Mon Jan 28 14:33:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 14:33:57 -0800 Subject: Review Request (XS) 8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <5106FCD5.804@oracle.com> Please, review the fix for (it was already reviewed by Christian): https://jbs.oracle.com/bugs/browse/JDK-8006731 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006731-JVMTI-JSR292.0 Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well. Take the interpreter/rewrite.cpp::Rewriter::rewrite_invokedynamic() as an example. Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Thanks, Serguei From eric.mccorkle at oracle.com Mon Jan 28 15:04:55 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 28 Jan 2013 18:04:55 -0500 Subject: Review request for JDK-8006949: Update hotspot for MethodParameters format change In-Reply-To: <5106F1E5.7020808@oracle.com> References: <5106D4AE.9050200@oracle.com> <5106F1E5.7020808@oracle.com> Message-ID: <51070417.3000503@oracle.com> I realized that I can detect when the flags are sized u4 versus u2 by looking at attribute_length. I am modifying the patch to support *both* sizes; however, going forward, tools and implementations should only produce and consume u2. I will post an updated webrev once I've run the end-to-end tests with both flavors. On 01/28/13 16:47, Coleen Phillimore wrote: > > This is nice change to have the flags smaller. The method parameter > tests are disabled and method parameters aren't found in the JDK > classfiles yet, so this will not fail with a version of the JDK that has > the flags as u4, right? > > Thanks, > Coleen > > On 01/28/2013 02:42 PM, Eric McCorkle wrote: >> Hello, >> >> Please review this patch, which updates hotspot in accordance with >> changes to the class file format of MethodParameters attributes. >> >> The latest spec version is here: >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> Any questions regarding the format change or the spec should be directed >> to Alex Buckley, the spec owner. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8006949/ >> >> The enhancement request is here: >> http://bugs.sun.com/view_bug.do?bug_id=8006949 >> >> The following CCC has been filed for this change: >> http://ccc.us.oracle.com/8006948 >> >> >> The end-to-end tests for MethodParameters are presently disabled; >> however, I have run the end-to-end tests with this patch, as well as the >> companion patch for JDK-8006948, and seen no failures. >> >> I am presently running testlist and JPRT jobs; however, given the >> extremely small nature of the changeset, I do not anticipate seeing any >> failures. >> >> Thanks, >> Eric > From coleen.phillimore at oracle.com Mon Jan 28 15:55:14 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Jan 2013 18:55:14 -0500 Subject: Review Request (XS) 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() In-Reply-To: <5106FCC7.4050201@oracle.com> References: <50F71FB2.4020702@oracle.com> <5106FCC7.4050201@oracle.com> Message-ID: <51070FE2.1020804@oracle.com> This looks good. I assume that this is tested with the mlvm nsk tests? Thanks, Coleen On 1/28/2013 5:33 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for (it was already reviewed by Christian): > https://jbs.oracle.com/bugs/browse/JDK-8006546 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006546-JVMTI-JSR292.0 > > > > Summary: > The copy_operands() does the same copy frrom dest cpool twice in two > places. > Instead, it must copy once from dest and once from source cpool. > It would make it consistent with the comments. > > > Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > > > Thanks, > Serguei > > From serguei.spitsyn at oracle.com Mon Jan 28 16:24:04 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 16:24:04 -0800 Subject: Review Request (XS) 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() In-Reply-To: <51070FE2.1020804@oracle.com> References: <50F71FB2.4020702@oracle.com> <5106FCC7.4050201@oracle.com> <51070FE2.1020804@oracle.com> Message-ID: <510716A4.4090107@oracle.com> Thanks! In fact, I did not test it with all the mlvm nsk tests, but agreed it is worth to do. I'll run the mlvm tests before the integration. Thanks, Serguei On 1/28/13 3:55 PM, Coleen Phillimore wrote: > > This looks good. I assume that this is tested with the mlvm nsk tests? > Thanks, > Coleen > > On 1/28/2013 5:33 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for (it was already reviewed by Christian): >> https://jbs.oracle.com/bugs/browse/JDK-8006546 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006546-JVMTI-JSR292.0 >> >> >> >> Summary: >> The copy_operands() does the same copy frrom dest cpool twice in >> two places. >> Instead, it must copy once from dest and once from source cpool. >> It would make it consistent with the comments. >> >> >> Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, >> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >> >> >> Thanks, >> Serguei >> >> From eric.mccorkle at oracle.com Mon Jan 28 17:45:35 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 28 Jan 2013 20:45:35 -0500 Subject: Review request for JDK-8006949: Update hotspot for MethodParameters format change In-Reply-To: <51070417.3000503@oracle.com> References: <5106D4AE.9050200@oracle.com> <5106F1E5.7020808@oracle.com> <51070417.3000503@oracle.com> Message-ID: <510729BF.0@oracle.com> I have posted a new webrev with code that is capable of loading classfiles with both 2 and 4 byte flags fields. Again, consider 4 byte flags fields to be temporary; *do not* count on this ability in future versions. On 01/28/13 18:04, Eric McCorkle wrote: > I realized that I can detect when the flags are sized u4 versus u2 by > looking at attribute_length. > > I am modifying the patch to support *both* sizes; however, going > forward, tools and implementations should only produce and consume u2. > > I will post an updated webrev once I've run the end-to-end tests with > both flavors. > > On 01/28/13 16:47, Coleen Phillimore wrote: >> >> This is nice change to have the flags smaller. The method parameter >> tests are disabled and method parameters aren't found in the JDK >> classfiles yet, so this will not fail with a version of the JDK that has >> the flags as u4, right? >> >> Thanks, >> Coleen >> >> On 01/28/2013 02:42 PM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this patch, which updates hotspot in accordance with >>> changes to the class file format of MethodParameters attributes. >>> >>> The latest spec version is here: >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>> Any questions regarding the format change or the spec should be directed >>> to Alex Buckley, the spec owner. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8006949/ >>> >>> The enhancement request is here: >>> http://bugs.sun.com/view_bug.do?bug_id=8006949 >>> >>> The following CCC has been filed for this change: >>> http://ccc.us.oracle.com/8006948 >>> >>> >>> The end-to-end tests for MethodParameters are presently disabled; >>> however, I have run the end-to-end tests with this patch, as well as the >>> companion patch for JDK-8006948, and seen no failures. >>> >>> I am presently running testlist and JPRT jobs; however, given the >>> extremely small nature of the changeset, I do not anticipate seeing any >>> failures. >>> >>> Thanks, >>> Eric >> From john.r.rose at oracle.com Mon Jan 28 18:13:04 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Jan 2013 18:13:04 -0800 Subject: Review request for JDK-8006949: Update hotspot for MethodParameters format change In-Reply-To: <510729BF.0@oracle.com> References: <5106D4AE.9050200@oracle.com> <5106F1E5.7020808@oracle.com> <51070417.3000503@oracle.com> <510729BF.0@oracle.com> Message-ID: Good. Count me as a reviewer. You should file a tracking bug for removing the old format. I suggest putting the bug id in a nearby comment. (I think in this case it's good to put in a bug number because it is a transient comment that helps clean the code.) If there are detailed reg tests that detect the 0x10000 flag that was changed to 0x8000 consider translating it in 4-byte mode, for a smoother ride. Nice job! -- John (on my iPhone) On Jan 28, 2013, at 5:45 PM, Eric McCorkle wrote: > I have posted a new webrev with code that is capable of loading > classfiles with both 2 and 4 byte flags fields. > > Again, consider 4 byte flags fields to be temporary; *do not* count on > this ability in future versions. From christian.thalinger at oracle.com Mon Jan 28 18:19:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Jan 2013 18:19:10 -0800 Subject: Unsafe.getObject() doesn't get loop hoisted in C2 In-Reply-To: <50E2CF38.9070604@infinite-source.de> References: <50E2CF38.9070604@infinite-source.de> Message-ID: On Jan 1, 2013, at 3:57 AM, Aaron Grunthal wrote: > While trying to optimize the JRuby runtime I've run into a field that's declared volatile but would benefit from non-volatile accesses for some important read operations. > > I've tried to use Unsafe.getObject to achieve identical semantics to a non-volatile field access, but it seems like hotspot C2 cannot perform loop invariant code motion on getObject. I.e. it's losing one of the major performance benefits of non-volatile accesses since the volatile read itself is not that expensive, at least on x86. > > My alternative is to declare the field as non-volatile and use Unsafe for volatile/atomic access in all other places, but this is something I would like to avoid as it seems more brittle than using getObject only in a few places (like CHM does for example). > > The question is whether this is intentional or something that should be fixed? My guess is that C2 emits a memory barrier. I suggest to read LibraryCallKit::inline_unsafe_access. -- Chris > > - Aaron > > test + disassembly : https://gist.github.com/4420897#file-test-java > compilable test: https://gist.github.com/4426366 > Originally reported in concurrency-interest: > http://cs.oswego.edu/pipermail/concurrency-interest/2013-January/010520.html From serguei.spitsyn at oracle.com Mon Jan 28 20:28:51 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 20:28:51 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5106F91B.4040900@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> <5106F91B.4040900@oracle.com> Message-ID: <51075003.9000307@oracle.com> Coleen, This is a version with a refactoring you requested: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.3/ Now, the NameAndType, FieldRef, InterfaceMethodRef and MethodRef use the find_or_append_indirect_entry(). Thanks, Serguei On 1/28/13 2:18 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > This is a new webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ > > > As you pointed out, the InvokeDynamic entry support should also do > cross-checks with > the bootstrap method operands (arguments) and recursive extra appends > if necessary. > > I've filed a separate bug to track this issue: > https://jbs.oracle.com/bugs/browse/JDK-8007037 > > I want to separate this issue to be able to integrate what I have now > and concentrate on the rest later. > The VM SQE team developed new INDY tests that cover the > RedefineClasses issues. > I hope to adopt and use new tests soon to make sure most of the issues > are actually resolved. > > > Thanks, > Serguei > > > On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> >> Thank you a lot for the review! >> >> On 1/24/13 3:55 PM, Coleen Phillimore wrote: >>> >>> Hi Serguei, >>> >>> Putting functions in alphabetical order seems silly, it's better to >>> have utility functions directly above (or below) the function that >>> calls them. I'd take out the comment. >>> >>> I have started looking at this code a bit. This function >>> find_or_append_indirect_entry() should be used for the other >>> indirect entries also, shouldn't it? The code looks familiar to the >>> inside of the case statement to FieldRef, InterfaceRef and MethodRef. >> >> You've got it right. >> Yes, I noticed it but did not want to mess with it until it is proven >> to work well. >> My plan was to fix it for the FieldRef, InterfaceRef and MethodRef in >> a next round of fixes. >> >>> >>> Also is boot_spec an indirect index too that has to be appended? >>> >>> 564 int boot_spec = >>> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); >> >> This is a nice catch, will fix it. >> I thought, it is an index into the operands array, but it refers to a >> CONSTANT_MethodHandle element. >> >> >> Thanks, >> Serguei >> >> >>> >>> >>> Thanks, >>> Coleen >>> >>> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>>> Christian, >>>> >>>> >>>> Thank you a lot for the review! >>>> >>>> Nice catch with the ordering. >>>> In fact, I tried to follow the order but missed that the >>>> find_new_index should go first. :) >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>>> Please, review the fix for: >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>>> >>>>> + // Support for constant pool merging (these routines are in >>>>> alpha order): >>>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>>> + int find_or_append_indirect_entry(constantPoolHandle >>>>> scratch_cp, int scratch_i, >>>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>>> int find_new_index(int old_index); >>>>> >>>>> Not really alpha order ;-) >>>>> >>>>> Otherwise this looks good (as far as I can tell). >>>>> >>>>> -- Chris >>>>> >>>>>> Summary: >>>>>> Need a support for invokedynamic entry kinds when new and old >>>>>> constant pools are merged. >>>>>> >>>>>> Testing: >>>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>>> Asked the VM SQE team to develop new INDY tests for better >>>>>> coverage. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>> >>> >> > From markus.gronlund at oracle.com Tue Jan 29 01:54:28 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 29 Jan 2013 01:54:28 -0800 (PST) Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case Message-ID: Hi all, ? Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. ? Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 Webrev: ?http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01/ ? Also need someone to sponsor this putback. ? Thanks in advance Markus From mikael.gerdin at oracle.com Tue Jan 29 01:58:41 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 29 Jan 2013 10:58:41 +0100 Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: References: Message-ID: <51079D51.4070504@oracle.com> Markus, On 2013-01-29 10:54, Markus Gr?nlund wrote: > Hi all, > > > > Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. > > > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 > > Webrev: http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01/ This URL is not available from outside Oracle. /Mikael > > > > Also need someone to sponsor this putback. > > > > Thanks in advance > > Markus > -- Mikael Gerdin Java SE VM SQE Stockholm From markus.gronlund at oracle.com Tue Jan 29 02:10:59 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 29 Jan 2013 02:10:59 -0800 (PST) Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <51079D51.4070504@oracle.com> References: <51079D51.4070504@oracle.com> Message-ID: Hi again, Apologies for posting the wrong webrev link, this is the one I wanted to submit: Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ Thanks Mikael for the heads up Cheers Markus -----Original Message----- From: Mikael Gerdin Sent: den 29 januari 2013 10:59 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case Markus, On 2013-01-29 10:54, Markus Gr?nlund wrote: > Hi all, > > > > Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. > > > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 > > Webrev: http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01/ This URL is not available from outside Oracle. /Mikael > > > > Also need someone to sponsor this putback. > > > > Thanks in advance > > Markus > -- Mikael Gerdin Java SE VM SQE Stockholm From stefan.karlsson at oracle.com Tue Jan 29 02:58:00 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 29 Jan 2013 11:58:00 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal Message-ID: <5107AB38.4080107@oracle.com> http://cr.openjdk.java.net/~stefank/8004710/webrev/ This bug is in the GC specific code in the SA agent. From the bug report: There's a bug in ObjectHeap.collectLiveRegions(), which tries to collect the regions of the heap that contain live objects. It removes the [top, end) regions of a TLAB, since we don't have live objects in those regions. Unfortunately, this doesn't consider the small alignment_reserve() part at the end of the TLAB, and we try to decode an object in that unused memory region. It's not related to the PermGen removal, but the failure mode was probably changed. thanks, StefanK From zhengyu.gu at oracle.com Tue Jan 29 07:33:54 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 29 Jan 2013 10:33:54 -0500 Subject: Code review request: JDK-8000692, Remove old KERNEL code (JDK7 backport) Message-ID: <5107EBE2.3000801@oracle.com> Hi, This is JDK7 backport. It has enough differences, I think it should get separate code review. http://cr.openjdk.java.net/~zgu/8000692/backport/webrev.00/ Thanks, -Zhengyu From Bob.Vandette at oracle.COM Tue Jan 29 11:28:41 2013 From: Bob.Vandette at oracle.COM (Bob Vandette) Date: Tue, 29 Jan 2013 14:28:41 -0500 Subject: JEP for adding support for static JNI libraries Message-ID: <6867C2FE-6885-4030-A7CB-BCBA4CD390F6@oracle.COM> Please review this JEP I'd like to propose for Java SE 8. -------------- next part -------------- Bob Vandette Java SE Embedded Architect From bob.vandette at oracle.com Tue Jan 29 11:44:32 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 29 Jan 2013 14:44:32 -0500 Subject: Please review this JEP I'd like to propose for Java SE 8. Message-ID: <74F15266-C949-4EBE-AA28-E55ED53E3B48@oracle.com> Resending, mailer stripped out my attachment. Please review this JEP I'd like to propose for Java SE 8. Bob Vandette Java SE Embedded Architect -------------------------------------------------------------------------------------------- Title: Add support for static JNI libraries Author: Bob Vandette Organization: Oracle Java SE Embedded Owner: Bob Vandette Created: 2913/01/23 Type: Feature State: Draft Exposure: Open Component: core/libs Scope: SE RFE: 8005716 Discussion: jdk8 dash dev at openjdk dot java dot net Start: 2013/Q1 Effort: XS Duration: XS Template: 1.0 Reviewed-by: Alan Bateman Endorsed-by: Michael Vidsted Funded-by: Oracle Java SE Summary ------- The JNI specification doesn't fully support or specify how to use statically linked native libraries. There are at least two possible uses for this. 1. Native applications that embedded the JRE may wish to use statically linked JNI code rather than dynamically linked libraries. 2. Java applications that are developed for devices where shared libraries are not supported. On this type of platform, the JRE and all of it's supported JNI native code would be linked into a single application binary. At least two problems need to be addressed: 1. The current Java APIs that are used to initiate the loading process and as a result allow the native library entrypoints to be recognized need to be enhanced to support build-in libraries. A Java application wishing to use a build-in JNI library need a mechanism for notifying the VM that this library code is already included in the application image. In this situation, a System.loadLibrary request for a built-in library should avoid the platform native load but process the library as if the load succeeded. The current JNI specification alludes to this type of support but the currentHotspot VM does not support this behavior. "If the underlying operating system does not support dynamic linking, all native methods must be prelinked with the VM. In this case, the VM completes the System.loadLibrary call without actually loading the library." 2. The JNI_OnLoad and JNI_OnUnload function interface need to be enhanced to support library specific names since only a single function name can exist within an application. This could be implemented by appending the library name to these well-known-names. For example libnet.so could use JNI_OnLoad_net, JNI_OnUnload_net. Goals ----- 1. Modify the specification and implementation of Java SE in order to enable developers to build a java runtime into a single Java application binary without requiring the use of shared libraries. 2. Maintain Java source level compatibility. For example: System.loadLibrary("foobar") APIs should be able to transparently load dynamic or static libraries. 3. Support Java applications that use a combination of static and/or dynamic libraries. 4. Static libraries must be in memory prior to the initialization of the VM. Static libraries should not be linked with other dynamic shared libraries. Non-Goals --------- Complete native C/C++ source compatibility in not expected. It is expected that some minimal source changes will be required in order to rename the JNI_OnLoad and JNI_OnUnLoad functions in order to allow multiple static libraries to co-exist. Success Metrics --------------- This feature will be successful when there is support for static linkingand mixed static/dynamic linking in a Java runtime. Motivation ---------- Having the ability to link JNI static libraries within Java applications provides multiple benefits: 1. Enables the Link Time Optimization supported by most linkers to perform optimizations across the entire application. This results in smaller and faster executable. 2. Allows for the possibility of supporting Java SE on platforms that limit or do not support dynamic shared libraries. Description ----------- This change requires specification changes to both the Java SE library loading APIs and the JNI specification. Here is an initial draft of the specification updates in both areas: JAVA LIBRARY API CHANGES System.load, Runtime.load method Changes The System.load and Runtime.load specification descriptions will be change in to: Loads the native library specified by the filename argument. The filename argument must be an absolute path name. If the filename argument, when stripped of any platform-specific library prefix, path, and file extension, indicates a library whose name is L, and a native library called L is statically linked with the VM, then the JNI_OnLoad_L function exported by the library is invoked rather than attempting to load a dynamic library. A filename matching the argument does not have to exist in the file system. See the JNI Specification for more details. Otherwise, the filename argument is mapped to a native library image in an implementation-dependent manner. The UnsatisfiedLinkError - if either the filename is not an absolute path name, the native library is not statically linked with the VM, or the library cannot be mapped to a native library image by the host system. System.loadLibrary, Runtime.loadLibrary changes The System.loadLibrary and Runtime.loadLibrary specification descriptions will be changed to: Loads the native library specified by the libname argument. The libname argument must not contain any platform specific prefix, file extension or path. If a native library called libname is statically linked with the VM, then the JNI_OnLoad_libname function exported by the library is invoked. See the JNI Specification for more details. Otherwise, the libname argument is loaded from a system library location and mapped to a native library image in an implementation-dependent manner. The UnsatisfiedLinkError - if either the libname argument contains a file path, the native library is not statically linked with the VM, or the library cannot be mapped to a native library image by the host system. JNI SPECIFICATION CHANGE - A native library may be statically linked with the VM. The manner in which the library and VM image are combined is implementation-dependent. - A System.loadLibrary or equivalent API must succeed for this library to be considered loaded. - A library L whose image has been combined with the VM is defined as _statically linked_ if and only if the library exports a function called JNI_OnLoad_L. - If a _statically linked_ library L exports a function called JNI_OnLoad_L _and_ a function called JNI_OnLoad, the JNI_OnLoad function will be ignored. - If a library L is _statically linked_, then upon the first invocation of System.loadLibrary("L") or equivalent API, the Java runtime will invoke the JNI_OnLoad_L function with the same arguments and expected return value as specified for the JNI_OnLoad function. - A library L that is _statically linked_ will prohibit a library of the same name from being loaded dynamically. - When the class loader containing a _statically linked_ native library L is garbage collected, the VM will invoke the JNI_OnUnload_L function of the library if such a function is exported. - If a _statically linked_ library L exports a function called JNI_OnUnLoad_L _and_ a function called JNI_OnUnLoad, the JNI_OnUnLoad function will be ignored. The JNI version specification will be incremented to JNI_VERSION_1_8. This new functionality will only be supported in JNI_VERSION_1_8 or greater. Alternatives ------------ There are no alternatives. Testing ------- The JNI TCK tests need to be enhanced to validate native static libraries in addition to the currently supported dynamic libraries. Impact ------ - Compatibility: New configuration no issues with existing dynamic libraries - Portability: JNI native sources require function name changes when built static - Documentation: javadoc for impacted java/lang APIS and JNI specification - TCK: TCK JNI native library will need to be ported as a static lib From zhengyu.gu at oracle.com Tue Jan 29 13:48:25 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 29 Jan 2013 21:48:25 +0000 Subject: hg: hsx/hsx24/hotspot: 6871190: Don't terminate JVM if it is running in a non-interactive session Message-ID: <20130129214830.E5B1847679@hg.openjdk.java.net> Changeset: 21b0918ed779 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/21b0918ed779 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp From coleen.phillimore at oracle.com Tue Jan 29 13:49:19 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 29 Jan 2013 16:49:19 -0500 Subject: Code review request: JDK-8000692, Remove old KERNEL code (JDK7 backport) In-Reply-To: <5107EBE2.3000801@oracle.com> References: <5107EBE2.3000801@oracle.com> Message-ID: <510843DF.3080505@oracle.com> This looks good! Coleen On 01/29/2013 10:33 AM, Zhengyu Gu wrote: > Hi, > > This is JDK7 backport. It has enough differences, I think it should > get separate code review. > > http://cr.openjdk.java.net/~zgu/8000692/backport/webrev.00/ > > Thanks, > > -Zhengyu From jon.masamitsu at oracle.com Tue Jan 29 13:53:17 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 29 Jan 2013 13:53:17 -0800 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <5107AB38.4080107@oracle.com> References: <5107AB38.4080107@oracle.com> Message-ID: <510844CD.7050907@oracle.com> Stefan, Changes look correct. Did you consider calculating the value for endReserve() all in the VM (similar to the way ReserveForAllocationPrefetch is calculated during initialization) and passing the value to the SA the way ReserveForAllocationPrefetch is passed? If ReserveForAllocationPrefetch is not used anywhere else, you could substitute it (TLabEndReserve as a possible name) for ReserveForAllocationPrefetch. Jon On 01/29/13 02:58, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8004710/webrev/ > > This bug is in the GC specific code in the SA agent. > > From the bug report: > There's a bug in ObjectHeap.collectLiveRegions(), which tries to > collect the regions of the heap that contain live objects. It removes > the [top, end) regions of a TLAB, since we don't have live objects in > those regions. Unfortunately, this doesn't consider the small > alignment_reserve() part at the end of the TLAB, and we try to decode > an object in that unused memory region. > > It's not related to the PermGen removal, but the failure mode was > probably changed. > > thanks, > StefanK > From stefan.karlsson at oracle.com Tue Jan 29 14:01:16 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 29 Jan 2013 23:01:16 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <510844CD.7050907@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> Message-ID: <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> On 29 jan 2013, at 22:53, Jon Masamitsu wrote: > Stefan, > > Changes look correct. Thanks. > > Did you consider calculating the value for endReserve() all > in the VM (similar to the way ReserveForAllocationPrefetch > is calculated during initialization) and passing the value > to the SA the way ReserveForAllocationPrefetch is passed? > If ReserveForAllocationPrefetch is not used anywhere else, > you could substitute it (TLabEndReserve as a possible name) > for ReserveForAllocationPrefetch. No i didn't think about that. I just tried to mimic the VM code in the SA code. Would you prefer if I changed it to use your alternative solution? thanks, StefanK > > Jon > > On 01/29/13 02:58, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >> >> This bug is in the GC specific code in the SA agent. >> >> From the bug report: >> There's a bug in ObjectHeap.collectLiveRegions(), which tries to collect the regions of the heap that contain live objects. It removes the [top, end) regions of a TLAB, since we don't have live objects in those regions. Unfortunately, this doesn't consider the small alignment_reserve() part at the end of the TLAB, and we try to decode an object in that unused memory region. >> >> It's not related to the PermGen removal, but the failure mode was probably changed. >> >> thanks, >> StefanK >> From alejandro.murillo at oracle.com Tue Jan 29 15:04:04 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 29 Jan 2013 16:04:04 -0700 Subject: Code review request CR 8007101: make jdk7u14 the default jprt release for hs24 Message-ID: <51085564.10802@oracle.com> Can someone please review this small change: make jdk7u14 the default jprt release for hs24 http://cr.openjdk.java.net/~amurillo/webrevs/8007101/ 8007101 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007101: make jdk7u14 the default jprt release for hs24 thanks -- Alejandro From kelly.ohair at oracle.com Tue Jan 29 15:15:23 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 29 Jan 2013 15:15:23 -0800 Subject: Code review request CR 8007101: make jdk7u14 the default jprt release for hs24 In-Reply-To: <51085564.10802@oracle.com> References: <51085564.10802@oracle.com> Message-ID: Looks ok to me. -kto On Jan 29, 2013, at 3:04 PM, Alejandro E Murillo wrote: > > Can someone please review this small change: make jdk7u14 the default jprt release for hs24 > > http://cr.openjdk.java.net/~amurillo/webrevs/8007101/ > > 8007101 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007101: make jdk7u14 the default jprt release for hs24 > > thanks > > -- > Alejandro > From daniel.daugherty at oracle.com Tue Jan 29 15:35:40 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 29 Jan 2013 16:35:40 -0700 Subject: Code review request CR 8007101: make jdk7u14 the default jprt release for hs24 In-Reply-To: <51085564.10802@oracle.com> References: <51085564.10802@oracle.com> Message-ID: <51085CCC.1020605@oracle.com> Thumbs up. Please change copyright year to 2013. :-) Dan On 1/29/13 4:04 PM, Alejandro E Murillo wrote: > > Can someone please review this small change: make jdk7u14 the default > jprt release for hs24 > > http://cr.openjdk.java.net/~amurillo/webrevs/8007101/ > > 8007101 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007101: > make jdk7u14 the default jprt release for hs24 > > thanks > From alejandro.murillo at oracle.com Tue Jan 29 15:52:24 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 29 Jan 2013 16:52:24 -0700 Subject: Code review request CR 8007101: make jdk7u14 the default jprt release for hs24 In-Reply-To: <51085CCC.1020605@oracle.com> References: <51085564.10802@oracle.com> <51085CCC.1020605@oracle.com> Message-ID: <510860B8.4020007@oracle.com> will do, thanks guys Alejandro On 1/29/2013 4:35 PM, Daniel D. Daugherty wrote: > Thumbs up. Please change copyright year to 2013. :-) > > Dan > > > On 1/29/13 4:04 PM, Alejandro E Murillo wrote: >> >> Can someone please review this small change: make jdk7u14 the >> default jprt release for hs24 >> >> http://cr.openjdk.java.net/~amurillo/webrevs/8007101/ >> >> 8007101 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007101: >> make jdk7u14 the default jprt release for hs24 >> >> thanks >> > From jon.masamitsu at oracle.com Tue Jan 29 16:18:53 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 29 Jan 2013 16:18:53 -0800 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> Message-ID: <510866ED.7010400@oracle.com> On 01/29/13 14:01, Stefan Karlsson wrote: > On 29 jan 2013, at 22:53, Jon Masamitsu wrote: > >> Stefan, >> >> Changes look correct. > Thanks. > >> Did you consider calculating the value for endReserve() all >> in the VM (similar to the way ReserveForAllocationPrefetch >> is calculated during initialization) and passing the value >> to the SA the way ReserveForAllocationPrefetch is passed? >> If ReserveForAllocationPrefetch is not used anywhere else, >> you could substitute it (TLabEndReserve as a possible name) >> for ReserveForAllocationPrefetch. > No i didn't think about that. I just tried to mimic the VM code in the SA code. Would you prefer if I changed it to use your alternative solution? If you can hide that type of detail from the SA, I think it's worth a little bit more work. Since it's already broken, you can put the change into hotspot first and then push the change to use it later. Thanks. Jon > > thanks, > StefanK > > >> Jon >> >> On 01/29/13 02:58, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>> >>> This bug is in the GC specific code in the SA agent. >>> >>> From the bug report: >>> There's a bug in ObjectHeap.collectLiveRegions(), which tries to collect the regions of the heap that contain live objects. It removes the [top, end) regions of a TLAB, since we don't have live objects in those regions. Unfortunately, this doesn't consider the small alignment_reserve() part at the end of the TLAB, and we try to decode an object in that unused memory region. >>> >>> It's not related to the PermGen removal, but the failure mode was probably changed. >>> >>> thanks, >>> StefanK >>> From alejandro.murillo at oracle.com Tue Jan 29 17:55:08 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 30 Jan 2013 01:55:08 +0000 Subject: hg: hsx/hsx24/hotspot: 8007101: make jdk7u14 the default jprt release for hs24 Message-ID: <20130130015512.BF56047681@hg.openjdk.java.net> Changeset: fed67a49fd2c Author: amurillo Date: 2013-01-29 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fed67a49fd2c 8007101: make jdk7u14 the default jprt release for hs24 Reviewed-by: jcoomes, ohair, dcubed ! make/jprt.properties From christian.thalinger at oracle.com Tue Jan 29 20:16:30 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 30 Jan 2013 04:16:30 +0000 Subject: hg: hsx/hsx24/hotspot: 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Message-ID: <20130130041635.68A4A4768C@hg.openjdk.java.net> Changeset: b1f34a2b2e22 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b1f34a2b2e22 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp From eric.mccorkle at oracle.com Wed Jan 30 08:00:58 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 30 Jan 2013 11:00:58 -0500 Subject: Review request for JDK-8006949: Update hotspot for MethodParameters format change In-Reply-To: References: <5106D4AE.9050200@oracle.com> <5106F1E5.7020808@oracle.com> <51070417.3000503@oracle.com> <510729BF.0@oracle.com> Message-ID: <510943BA.5040205@oracle.com> I've created JDK-8007154 to track this issue. The 0x10000 SYNTHESIZED flag, as was only a temporary assignment, so I did not create any regression tests for it (for this exact reason). On 01/28/13 21:13, John Rose wrote: > Good. Count me as a reviewer. > > You should file a tracking bug for removing the old format. I suggest putting the bug id in a nearby comment. (I think in this case it's good to put in a bug number because it is a transient comment that helps clean the code.) > > If there are detailed reg tests that detect the 0x10000 flag that was changed to 0x8000 consider translating it in 4-byte mode, for a smoother ride. > > Nice job! > > -- John (on my iPhone) > > On Jan 28, 2013, at 5:45 PM, Eric McCorkle wrote: > >> I have posted a new webrev with code that is capable of loading >> classfiles with both 2 and 4 byte flags fields. >> >> Again, consider 4 byte flags fields to be temporary; *do not* count on >> this ability in future versions. From jon.masamitsu at oracle.com Wed Jan 30 08:17:11 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 30 Jan 2013 08:17:11 -0800 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> Message-ID: <51094787.8020904@oracle.com> Comment below. On 1/29/2013 2:01 PM, Stefan Karlsson wrote: > On 29 jan 2013, at 22:53, Jon Masamitsu wrote: > >> Stefan, >> >> Changes look correct. > Thanks. > >> Did you consider calculating the value for endReserve() all >> in the VM (similar to the way ReserveForAllocationPrefetch >> is calculated during initialization) and passing the value >> to the SA the way ReserveForAllocationPrefetch is passed? >> If ReserveForAllocationPrefetch is not used anywhere else, >> you could substitute it (TLabEndReserve as a possible name) >> for ReserveForAllocationPrefetch. > No i didn't think about that. I just tried to mimic the VM code in the SA code. Would you prefer if I changed it to use your alternative solution? Scrap the alternate fix suggestion but I'd suggest changing the name intArrayHeaderSize to minFillerArraySize What caught my eye about this change is that it was hard to understand the use of intArrayHeaderSize unless you knew that tlab's had filler arrays inserted in them to make them parsable and hotspot saved room at the end of each tlab so that a filler object could always be inserted. If you make the name change that give the reader a clue to that. Ship it. Jon > thanks, > StefanK > > >> Jon >> >> On 01/29/13 02:58, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>> >>> This bug is in the GC specific code in the SA agent. >>> >>> From the bug report: >>> There's a bug in ObjectHeap.collectLiveRegions(), which tries to collect the regions of the heap that contain live objects. It removes the [top, end) regions of a TLAB, since we don't have live objects in those regions. Unfortunately, this doesn't consider the small alignment_reserve() part at the end of the TLAB, and we try to decode an object in that unused memory region. >>> >>> It's not related to the PermGen removal, but the failure mode was probably changed. >>> >>> thanks, >>> StefanK >>> From stefan.karlsson at oracle.com Wed Jan 30 08:22:00 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 30 Jan 2013 17:22:00 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <51094787.8020904@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> <51094787.8020904@oracle.com> Message-ID: On 30 jan 2013, at 17:17, Jon Masamitsu wrote: > Comment below. > > On 1/29/2013 2:01 PM, Stefan Karlsson wrote: >> On 29 jan 2013, at 22:53, Jon Masamitsu wrote: >> >>> Stefan, >>> >>> Changes look correct. >> Thanks. >> >>> Did you consider calculating the value for endReserve() all >>> in the VM (similar to the way ReserveForAllocationPrefetch >>> is calculated during initialization) and passing the value >>> to the SA the way ReserveForAllocationPrefetch is passed? >>> If ReserveForAllocationPrefetch is not used anywhere else, >>> you could substitute it (TLabEndReserve as a possible name) >>> for ReserveForAllocationPrefetch. >> No i didn't think about that. I just tried to mimic the VM code in the SA code. Would you prefer if I changed it to use your alternative solution? > > Scrap the alternate fix suggestion but I'd suggest changing the name > > intArrayHeaderSize > > to > > minFillerArraySize > > What caught my eye about this change is that it was hard > to understand the use of intArrayHeaderSize unless you knew > that tlab's had filler arrays inserted in them to make them > parsable and hotspot saved room at the end of each tlab so > that a filler object could always be inserted. If you > make the name change that give the reader a clue to that. Sure, I'll update the name. Thanks again for the review. StefanK > > Ship it. > > Jon > > >> thanks, >> StefanK >> >> >>> Jon >>> >>> On 01/29/13 02:58, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>>> >>>> This bug is in the GC specific code in the SA agent. >>>> >>>> From the bug report: >>>> There's a bug in ObjectHeap.collectLiveRegions(), which tries to collect the regions of the heap that contain live objects. It removes the [top, end) regions of a TLAB, since we don't have live objects in those regions. Unfortunately, this doesn't consider the small alignment_reserve() part at the end of the TLAB, and we try to decode an object in that unused memory region. >>>> >>>> It's not related to the PermGen removal, but the failure mode was probably changed. >>>> >>>> thanks, >>>> StefanK >>>> From mikael.vidstedt at oracle.com Wed Jan 30 08:29:50 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 30 Jan 2013 08:29:50 -0800 Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: References: <51079D51.4070504@oracle.com> Message-ID: <51094A7E.5050909@oracle.com> Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? Cheers, Mikael On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: > Hi again, > > Apologies for posting the wrong webrev link, this is the one I wanted to submit: > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 > Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ > > > Thanks Mikael for the heads up > > Cheers > Markus > > > > -----Original Message----- > From: Mikael Gerdin > Sent: den 29 januari 2013 10:59 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case > > Markus, > > On 2013-01-29 10:54, Markus Gr?nlund wrote: >> Hi all, >> >> >> >> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >> >> >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >> >> Webrev: http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01/ > This URL is not available from outside Oracle. > > /Mikael > >> >> >> Also need someone to sponsor this putback. >> >> >> >> Thanks in advance >> >> Markus >> From markus.gronlund at oracle.com Wed Jan 30 09:45:16 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 09:45:16 -0800 (PST) Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <51094A7E.5050909@oracle.com> References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> Message-ID: Hi Mikael, I wonder if you are looking at the right section in the manual (and which manual?) here? I am using information in Intel Application note 485: http://www.intel.com/content/www/us/en/processors/processor-identification-cpuid-instruction-note.html Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the different levels in the cpu topology you are interested in. Results are given in EBX[15:0] [31:16] == reserved. "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this?" CPUID04 EAX[31:26] is giving you the number of cores [per cpu package] using the legacy "initial APICID (8-bits)" systems. This combined with CPUID 01[logical threads per cpu package] is the legacy way of cpu identification. It is cannot give you as much info as topology however. Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) for identification (SMT, Core, Pkg), and does not use "initial APICID". So: EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) ... Hope this clarifies Cheers Markus -----Original Message----- From: Mikael Vidstedt Sent: den 30 januari 2013 17:30 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? Cheers, Mikael On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: > Hi again, > > Apologies for posting the wrong webrev link, this is the one I wanted to submit: > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 > Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ > > > Thanks Mikael for the heads up > > Cheers > Markus > > > > -----Original Message----- > From: Mikael Gerdin > Sent: den 29 januari 2013 10:59 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is > wrong for cpuid 0xb topology case > > Markus, > > On 2013-01-29 10:54, Markus Gr?nlund wrote: >> Hi all, >> >> >> >> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >> >> >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >> >> Webrev: >> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01/ > This URL is not available from outside Oracle. > > /Mikael > >> >> >> Also need someone to sponsor this putback. >> >> >> >> Thanks in advance >> >> Markus >> From vladimir.kozlov at oracle.com Wed Jan 30 10:33:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 10:33:25 -0800 Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> Message-ID: <51096775.7080902@oracle.com> Markus, Current code is correct. In what case it is not correct? bash-4.1$ psrinfo -pv The physical processor has 8 cores and 16 virtual processors (0-7 16-23) The core has 2 virtual processors (0 16) The core has 2 virtual processors (1 17) The core has 2 virtual processors (2 18) The core has 2 virtual processors (3 19) The core has 2 virtual processors (4 20) The core has 2 virtual processors (5 21) The core has 2 virtual processors (6 22) The core has 2 virtual processors (7 23) x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version [SafePoint Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: 0xfffffd7fff1d0000] Logical CPUs per core: 2 UseSSE=4 UseAVX=1 UseAES=1 Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes 576 PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 cores per cpu, 2 threads per core) family 6 model 45 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, ht, tsc, tscinvbit, tscinv Thanks, Vladimir On 1/30/13 9:45 AM, Markus Gr?nlund wrote: > Hi Mikael, > > I wonder if you are looking at the right section in the manual (and which manual?) here? > > I am using information in Intel Application note 485: > > http://www.intel.com/content/www/us/en/processors/processor-identification-cpuid-instruction-note.html > > Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the different levels in the cpu topology you are interested in. Results are given in EBX[15:0] [31:16] == reserved. > > > "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this?" > > CPUID04 EAX[31:26] is giving you the number of cores [per cpu package] using the legacy "initial APICID (8-bits)" systems. This combined with CPUID 01[logical threads per cpu package] is the legacy way of cpu identification. It is cannot give you as much info as topology however. > > Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) for identification (SMT, Core, Pkg), and does not use "initial APICID". > > So: > > EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) > EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) > ... > > Hope this clarifies > > Cheers > Markus > > > > > > -----Original Message----- > From: Mikael Vidstedt > Sent: den 30 januari 2013 17:30 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case > > > Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? > > Cheers, > Mikael > > On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >> Hi again, >> >> Apologies for posting the wrong webrev link, this is the one I wanted to submit: >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >> >> >> Thanks Mikael for the heads up >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: Mikael Gerdin >> Sent: den 29 januari 2013 10:59 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> Markus, >> >> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>> Hi all, >>> >>> >>> >>> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >>> >>> >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>> >>> Webrev: >>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01/ >> This URL is not available from outside Oracle. >> >> /Mikael >> >>> >>> >>> Also need someone to sponsor this putback. >>> >>> >>> >>> Thanks in advance >>> >>> Markus >>> > From markus.gronlund at oracle.com Wed Jan 30 10:47:19 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 10:47:19 -0800 (PST) Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <51096775.7080902@oracle.com> References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> <51096775.7080902@oracle.com> Message-ID: Hi Vladimir, Yes I have noticed that it will give ok results (so far). For example, on my Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, (Sandybridge-EP). I have 8 hw threads (from os::processor_count()) Also, it's using CPUID 0xb (supports topology, 2xAPICID) My values are: _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 <<-- threads per core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per cpu package Current (wrong) logic does: No of cores per cpu: Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 == no of cores == 8 (correct). However, This does not account for CPUs that have HT enabled, i.e if HT is enabled, you will get this: _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 <<-- threads per core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per cpu package Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 == no of cores is now 4, but the real number of cores is 8. So, avoid doing the unnecessary divide operation (no_of_cores_per_pkg) / (no_of_threads_per_core). The correct info is already there. Just return it. Return: _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus // 8 correct Cheers Markus -----Original Message----- From: Vladimir Kozlov Sent: den 30 januari 2013 19:33 To: Markus Gr?nlund Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case Markus, Current code is correct. In what case it is not correct? bash-4.1$ psrinfo -pv The physical processor has 8 cores and 16 virtual processors (0-7 16-23) The core has 2 virtual processors (0 16) The core has 2 virtual processors (1 17) The core has 2 virtual processors (2 18) The core has 2 virtual processors (3 19) The core has 2 virtual processors (4 20) The core has 2 virtual processors (5 21) The core has 2 virtual processors (6 22) The core has 2 virtual processors (7 23) x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version [SafePoint Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: 0xfffffd7fff1d0000] Logical CPUs per core: 2 UseSSE=4 UseAVX=1 UseAES=1 Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes 576 PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 cores per cpu, 2 threads per core) family 6 model 45 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, ht, tsc, tscinvbit, tscinv Thanks, Vladimir On 1/30/13 9:45 AM, Markus Gr?nlund wrote: > Hi Mikael, > > I wonder if you are looking at the right section in the manual (and which manual?) here? > > I am using information in Intel Application note 485: > > http://www.intel.com/content/www/us/en/processors/processor-identifica > tion-cpuid-instruction-note.html > > Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the different levels in the cpu topology you are interested in. Results are given in EBX[15:0] [31:16] == reserved. > > > "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this?" > > CPUID04 EAX[31:26] is giving you the number of cores [per cpu package] using the legacy "initial APICID (8-bits)" systems. This combined with CPUID 01[logical threads per cpu package] is the legacy way of cpu identification. It is cannot give you as much info as topology however. > > Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) for identification (SMT, Core, Pkg), and does not use "initial APICID". > > So: > > EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == > (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) > EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in > _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) > ... > > Hope this clarifies > > Cheers > Markus > > > > > > -----Original Message----- > From: Mikael Vidstedt > Sent: den 30 januari 2013 17:30 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is > wrong for cpuid 0xb topology case > > > Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? > > Cheers, > Mikael > > On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >> Hi again, >> >> Apologies for posting the wrong webrev link, this is the one I wanted to submit: >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >> >> >> Thanks Mikael for the heads up >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: Mikael Gerdin >> Sent: den 29 januari 2013 10:59 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> Markus, >> >> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>> Hi all, >>> >>> >>> >>> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >>> >>> >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>> >>> Webrev: >>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01 >>> / >> This URL is not available from outside Oracle. >> >> /Mikael >> >>> >>> >>> Also need someone to sponsor this putback. >>> >>> >>> >>> Thanks in advance >>> >>> Markus >>> > From vladimir.kozlov at oracle.com Wed Jan 30 10:57:55 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 10:57:55 -0800 Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> <51096775.7080902@oracle.com> Message-ID: <51096D33.7090309@oracle.com> No, the example I showed has HT and VM gives correct results: tpl_cpuidB0_ebx.bits.logical_cpus = 2 tpl_cpuidB1_ebx.bits.logical_cpus = 16 (8 cores per cpu, 2 threads per core) Vladimir On 1/30/13 10:47 AM, Markus Gr?nlund wrote: > Hi Vladimir, > > Yes I have noticed that it will give ok results (so far). For example, on my Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, (Sandybridge-EP). > > I have 8 hw threads (from os::processor_count()) > > Also, it's using CPUID 0xb (supports topology, 2xAPICID) > > My values are: > > _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 <<-- threads per core > _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per cpu package > > Current (wrong) logic does: > > No of cores per cpu: > > Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 == no of cores == 8 (correct). > > However, > > This does not account for CPUs that have HT enabled, i.e if HT is enabled, you will get this: > > _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 <<-- threads per core > _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per cpu package > > > Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 == no of cores is now 4, but the real number of cores is 8. > > So, avoid doing the unnecessary divide operation (no_of_cores_per_pkg) / (no_of_threads_per_core). The correct info is already there. Just return it. > > Return: _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus // 8 correct > > > Cheers > Markus > > > > -----Original Message----- > From: Vladimir Kozlov > Sent: den 30 januari 2013 19:33 > To: Markus Gr?nlund > Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case > > Markus, > > Current code is correct. In what case it is not correct? > > bash-4.1$ psrinfo -pv > The physical processor has 8 cores and 16 virtual processors (0-7 16-23) > The core has 2 virtual processors (0 16) > The core has 2 virtual processors (1 17) > The core has 2 virtual processors (2 18) > The core has 2 virtual processors (3 19) > The core has 2 virtual processors (4 20) > The core has 2 virtual processors (5 21) > The core has 2 virtual processors (6 22) > The core has 2 virtual processors (7 23) > x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) > Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz > > ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version [SafePoint Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: 0xfffffd7fff1d0000] Logical CPUs per core: 2 > UseSSE=4 UseAVX=1 UseAES=1 > Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes 576 PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 cores per cpu, 2 threads per core) family 6 model 45 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, ht, tsc, tscinvbit, tscinv > > Thanks, > Vladimir > > > On 1/30/13 9:45 AM, Markus Gr?nlund wrote: >> Hi Mikael, >> >> I wonder if you are looking at the right section in the manual (and which manual?) here? >> >> I am using information in Intel Application note 485: >> >> http://www.intel.com/content/www/us/en/processors/processor-identifica >> tion-cpuid-instruction-note.html >> >> Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the different levels in the cpu topology you are interested in. Results are given in EBX[15:0] [31:16] == reserved. >> >> >> "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this?" >> >> CPUID04 EAX[31:26] is giving you the number of cores [per cpu package] using the legacy "initial APICID (8-bits)" systems. This combined with CPUID 01[logical threads per cpu package] is the legacy way of cpu identification. It is cannot give you as much info as topology however. >> >> Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) for identification (SMT, Core, Pkg), and does not use "initial APICID". >> >> So: >> >> EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == >> (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) >> EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in >> _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) >> ... >> >> Hope this clarifies >> >> Cheers >> Markus >> >> >> >> >> >> -----Original Message----- >> From: Mikael Vidstedt >> Sent: den 30 januari 2013 17:30 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> >> Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? >> >> Cheers, >> Mikael >> >> On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >>> Hi again, >>> >>> Apologies for posting the wrong webrev link, this is the one I wanted to submit: >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >>> >>> >>> Thanks Mikael for the heads up >>> >>> Cheers >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: Mikael Gerdin >>> Sent: den 29 januari 2013 10:59 >>> To: Markus Gr?nlund >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>> wrong for cpuid 0xb topology case >>> >>> Markus, >>> >>> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>>> Hi all, >>>> >>>> >>>> >>>> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >>>> >>>> >>>> >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>> >>>> Webrev: >>>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev01 >>>> / >>> This URL is not available from outside Oracle. >>> >>> /Mikael >>> >>>> >>>> >>>> Also need someone to sponsor this putback. >>>> >>>> >>>> >>>> Thanks in advance >>>> >>>> Markus >>>> >> From markus.gronlund at oracle.com Wed Jan 30 11:09:23 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 11:09:23 -0800 (PST) Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <51096D33.7090309@oracle.com> References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> <51096775.7080902@oracle.com> <51096D33.7090309@oracle.com> Message-ID: <7b2b95e6-facb-4abb-958c-3a98911dd796@default> Vladimir, many thanks giving me a good example, I have only had _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1, so far. You are right, thank you for showing me this, I did not read the details on the Note2 on Core level well enough: "2. The number of factory-configured logical processors at this level is equal to the number of factory-configured cores * the number of factory-configured logical processors per core." It was my (mis)understanding that Core level did not multiply up to the SMT level(but id does as the note gives as well as your example explains). Many thanks Vladimir Cheers Markus -----Original Message----- From: Vladimir Kozlov Sent: den 30 januari 2013 19:58 To: Markus Gr?nlund Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case No, the example I showed has HT and VM gives correct results: tpl_cpuidB0_ebx.bits.logical_cpus = 2 tpl_cpuidB1_ebx.bits.logical_cpus = 16 (8 cores per cpu, 2 threads per core) Vladimir On 1/30/13 10:47 AM, Markus Gr?nlund wrote: > Hi Vladimir, > > Yes I have noticed that it will give ok results (so far). For example, on my Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, (Sandybridge-EP). > > I have 8 hw threads (from os::processor_count()) > > Also, it's using CPUID 0xb (supports topology, 2xAPICID) > > My values are: > > _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 <<-- threads per > core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per > cpu package > > Current (wrong) logic does: > > No of cores per cpu: > > Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 == no of cores == 8 (correct). > > However, > > This does not account for CPUs that have HT enabled, i.e if HT is enabled, you will get this: > > _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 <<-- threads per > core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per > cpu package > > > Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 == no of cores is now 4, but the real number of cores is 8. > > So, avoid doing the unnecessary divide operation (no_of_cores_per_pkg) / (no_of_threads_per_core). The correct info is already there. Just return it. > > Return: _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus // 8 correct > > > Cheers > Markus > > > > -----Original Message----- > From: Vladimir Kozlov > Sent: den 30 januari 2013 19:33 > To: Markus Gr?nlund > Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is > wrong for cpuid 0xb topology case > > Markus, > > Current code is correct. In what case it is not correct? > > bash-4.1$ psrinfo -pv > The physical processor has 8 cores and 16 virtual processors (0-7 16-23) > The core has 2 virtual processors (0 16) > The core has 2 virtual processors (1 17) > The core has 2 virtual processors (2 18) > The core has 2 virtual processors (3 19) > The core has 2 virtual processors (4 20) > The core has 2 virtual processors (5 21) > The core has 2 virtual processors (6 22) > The core has 2 virtual processors (7 23) > x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) > Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz > > ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version [SafePoint > Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: > 0xfffffd7fff1d0000] Logical CPUs per core: 2 > UseSSE=4 UseAVX=1 UseAES=1 > Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 > bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes 576 > PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 cores > per cpu, 2 threads per core) family 6 model 45 stepping 6, cmov, cx8, > fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, > ht, tsc, tscinvbit, tscinv > > Thanks, > Vladimir > > > On 1/30/13 9:45 AM, Markus Gr?nlund wrote: >> Hi Mikael, >> >> I wonder if you are looking at the right section in the manual (and which manual?) here? >> >> I am using information in Intel Application note 485: >> >> http://www.intel.com/content/www/us/en/processors/processor-identific >> a >> tion-cpuid-instruction-note.html >> >> Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the different levels in the cpu topology you are interested in. Results are given in EBX[15:0] [31:16] == reserved. >> >> >> "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this?" >> >> CPUID04 EAX[31:26] is giving you the number of cores [per cpu package] using the legacy "initial APICID (8-bits)" systems. This combined with CPUID 01[logical threads per cpu package] is the legacy way of cpu identification. It is cannot give you as much info as topology however. >> >> Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) for identification (SMT, Core, Pkg), and does not use "initial APICID". >> >> So: >> >> EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == >> (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) >> EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in >> _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) >> ... >> >> Hope this clarifies >> >> Cheers >> Markus >> >> >> >> >> >> -----Original Message----- >> From: Mikael Vidstedt >> Sent: den 30 januari 2013 17:30 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> >> Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? >> >> Cheers, >> Mikael >> >> On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >>> Hi again, >>> >>> Apologies for posting the wrong webrev link, this is the one I wanted to submit: >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >>> >>> >>> Thanks Mikael for the heads up >>> >>> Cheers >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: Mikael Gerdin >>> Sent: den 29 januari 2013 10:59 >>> To: Markus Gr?nlund >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>> wrong for cpuid 0xb topology case >>> >>> Markus, >>> >>> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>>> Hi all, >>>> >>>> >>>> >>>> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >>>> >>>> >>>> >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>> >>>> Webrev: >>>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev0 >>>> 1 >>>> / >>> This URL is not available from outside Oracle. >>> >>> /Mikael >>> >>>> >>>> >>>> Also need someone to sponsor this putback. >>>> >>>> >>>> >>>> Thanks in advance >>>> >>>> Markus >>>> >> From vladimir.kozlov at oracle.com Wed Jan 30 11:26:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 11:26:29 -0800 Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <7b2b95e6-facb-4abb-958c-3a98911dd796@default> References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> <51096775.7080902@oracle.com> <51096D33.7090309@oracle.com> <7b2b95e6-facb-4abb-958c-3a98911dd796@default> Message-ID: <510973E5.5020706@oracle.com> You are welcome. Yes, you have to read "small print" not only on financial documents but also in hw architecture manuals :( Regards, Vladimir On 1/30/13 11:09 AM, Markus Gr?nlund wrote: > Vladimir, > > many thanks giving me a good example, I have only had _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1, so far. > > You are right, thank you for showing me this, I did not read the details on the Note2 on Core level well enough: > > "2. The number of factory-configured logical processors at this level is equal to the number of factory-configured cores * the number of factory-configured logical processors per core." > > It was my (mis)understanding that Core level did not multiply up to the SMT level(but id does as the note gives as well as your example explains). > > Many thanks Vladimir > > Cheers > Markus > > > > -----Original Message----- > From: Vladimir Kozlov > Sent: den 30 januari 2013 19:58 > To: Markus Gr?nlund > Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case > > No, the example I showed has HT and VM gives correct results: > > tpl_cpuidB0_ebx.bits.logical_cpus = 2 > tpl_cpuidB1_ebx.bits.logical_cpus = 16 > > (8 cores per cpu, 2 threads per core) > > Vladimir > > On 1/30/13 10:47 AM, Markus Gr?nlund wrote: >> Hi Vladimir, >> >> Yes I have noticed that it will give ok results (so far). For example, on my Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, (Sandybridge-EP). >> >> I have 8 hw threads (from os::processor_count()) >> >> Also, it's using CPUID 0xb (supports topology, 2xAPICID) >> >> My values are: >> >> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 <<-- threads per >> core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per >> cpu package >> >> Current (wrong) logic does: >> >> No of cores per cpu: >> >> Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 == no of cores == 8 (correct). >> >> However, >> >> This does not account for CPUs that have HT enabled, i.e if HT is enabled, you will get this: >> >> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 <<-- threads per >> core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per >> cpu package >> >> >> Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 == no of cores is now 4, but the real number of cores is 8. >> >> So, avoid doing the unnecessary divide operation (no_of_cores_per_pkg) / (no_of_threads_per_core). The correct info is already there. Just return it. >> >> Return: _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus // 8 correct >> >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: den 30 januari 2013 19:33 >> To: Markus Gr?nlund >> Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> Markus, >> >> Current code is correct. In what case it is not correct? >> >> bash-4.1$ psrinfo -pv >> The physical processor has 8 cores and 16 virtual processors (0-7 16-23) >> The core has 2 virtual processors (0 16) >> The core has 2 virtual processors (1 17) >> The core has 2 virtual processors (2 18) >> The core has 2 virtual processors (3 19) >> The core has 2 virtual processors (4 20) >> The core has 2 virtual processors (5 21) >> The core has 2 virtual processors (6 22) >> The core has 2 virtual processors (7 23) >> x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) >> Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz >> >> ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version [SafePoint >> Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: >> 0xfffffd7fff1d0000] Logical CPUs per core: 2 >> UseSSE=4 UseAVX=1 UseAES=1 >> Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 >> bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes 576 >> PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 cores >> per cpu, 2 threads per core) family 6 model 45 stepping 6, cmov, cx8, >> fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, >> ht, tsc, tscinvbit, tscinv >> >> Thanks, >> Vladimir >> >> >> On 1/30/13 9:45 AM, Markus Gr?nlund wrote: >>> Hi Mikael, >>> >>> I wonder if you are looking at the right section in the manual (and which manual?) here? >>> >>> I am using information in Intel Application note 485: >>> >>> http://www.intel.com/content/www/us/en/processors/processor-identific >>> a >>> tion-cpuid-instruction-note.html >>> >>> Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the different levels in the cpu topology you are interested in. Results are given in EBX[15:0] [31:16] == reserved. >>> >>> >>> "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this?" >>> >>> CPUID04 EAX[31:26] is giving you the number of cores [per cpu package] using the legacy "initial APICID (8-bits)" systems. This combined with CPUID 01[logical threads per cpu package] is the legacy way of cpu identification. It is cannot give you as much info as topology however. >>> >>> Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) for identification (SMT, Core, Pkg), and does not use "initial APICID". >>> >>> So: >>> >>> EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == >>> (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) >>> EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in >>> _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) >>> ... >>> >>> Hope this clarifies >>> >>> Cheers >>> Markus >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Mikael Vidstedt >>> Sent: den 30 januari 2013 17:30 >>> To: Markus Gr?nlund >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>> wrong for cpuid 0xb topology case >>> >>> >>> Looking at the Intel manual for CPUID 0Bh it basically says that one should not use the value in EBX[15:0] for anything other than "...display/diagnostic purposes". There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the difference is? Is that maybe a better candidate for this? >>> >>> Cheers, >>> Mikael >>> >>> On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >>>> Hi again, >>>> >>>> Apologies for posting the wrong webrev link, this is the one I wanted to submit: >>>> >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >>>> >>>> >>>> Thanks Mikael for the heads up >>>> >>>> Cheers >>>> Markus >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Mikael Gerdin >>>> Sent: den 29 januari 2013 10:59 >>>> To: Markus Gr?nlund >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>>> wrong for cpuid 0xb topology case >>>> >>>> Markus, >>>> >>>> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> Kindly asking for review for the following very simple change in the logic for number of cores for CPUID 0xb topology. >>>>> >>>>> >>>>> >>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>>> >>>>> Webrev: >>>>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev0 >>>>> 1 >>>>> / >>>> This URL is not available from outside Oracle. >>>> >>>> /Mikael >>>> >>>>> >>>>> >>>>> Also need someone to sponsor this putback. >>>>> >>>>> >>>>> >>>>> Thanks in advance >>>>> >>>>> Markus >>>>> >>> From mikael.vidstedt at oracle.com Wed Jan 30 12:56:07 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 30 Jan 2013 12:56:07 -0800 Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <510973E5.5020706@oracle.com> References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> <51096775.7080902@oracle.com> <51096D33.7090309@oracle.com> <7b2b95e6-facb-4abb-958c-3a98911dd796@default> <510973E5.5020706@oracle.com> Message-ID: <510988E7.1070304@oracle.com> For completeness, I was looking at the instruction set reference (from January 2013), page 3-152 and 3-153, and specifically the double star ("**") note for the EBX value. http://download.intel.com/products/processor/manual/253666.pdf Cheers, Mikael On 2013-01-30 11:26, Vladimir Kozlov wrote: > You are welcome. > > Yes, you have to read "small print" not only on financial documents > but also in hw architecture manuals :( > > Regards, > Vladimir > > On 1/30/13 11:09 AM, Markus Gr?nlund wrote: >> Vladimir, >> >> many thanks giving me a good example, I have only had >> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1, so far. >> >> You are right, thank you for showing me this, I did not read the >> details on the Note2 on Core level well enough: >> >> "2. The number of factory-configured logical processors at this level >> is equal to the number of factory-configured cores * the number of >> factory-configured logical processors per core." >> >> It was my (mis)understanding that Core level did not multiply up to >> the SMT level(but id does as the note gives as well as your example >> explains). >> >> Many thanks Vladimir >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: den 30 januari 2013 19:58 >> To: Markus Gr?nlund >> Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> No, the example I showed has HT and VM gives correct results: >> >> tpl_cpuidB0_ebx.bits.logical_cpus = 2 >> tpl_cpuidB1_ebx.bits.logical_cpus = 16 >> >> (8 cores per cpu, 2 threads per core) >> >> Vladimir >> >> On 1/30/13 10:47 AM, Markus Gr?nlund wrote: >>> Hi Vladimir, >>> >>> Yes I have noticed that it will give ok results (so far). For >>> example, on my Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, >>> (Sandybridge-EP). >>> >>> I have 8 hw threads (from os::processor_count()) >>> >>> Also, it's using CPUID 0xb (supports topology, 2xAPICID) >>> >>> My values are: >>> >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 <<-- threads per >>> core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per >>> cpu package >>> >>> Current (wrong) logic does: >>> >>> No of cores per cpu: >>> >>> Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 == no of cores == >>> 8 (correct). >>> >>> However, >>> >>> This does not account for CPUs that have HT enabled, i.e if HT is >>> enabled, you will get this: >>> >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 <<-- threads per >>> core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores per >>> cpu package >>> >>> >>> Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 == no of cores is >>> now 4, but the real number of cores is 8. >>> >>> So, avoid doing the unnecessary divide operation >>> (no_of_cores_per_pkg) / (no_of_threads_per_core). The correct info >>> is already there. Just return it. >>> >>> Return: _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus // 8 correct >>> >>> >>> Cheers >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: den 30 januari 2013 19:33 >>> To: Markus Gr?nlund >>> Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>> wrong for cpuid 0xb topology case >>> >>> Markus, >>> >>> Current code is correct. In what case it is not correct? >>> >>> bash-4.1$ psrinfo -pv >>> The physical processor has 8 cores and 16 virtual processors (0-7 >>> 16-23) >>> The core has 2 virtual processors (0 16) >>> The core has 2 virtual processors (1 17) >>> The core has 2 virtual processors (2 18) >>> The core has 2 virtual processors (3 19) >>> The core has 2 virtual processors (4 20) >>> The core has 2 virtual processors (5 21) >>> The core has 2 virtual processors (6 22) >>> The core has 2 virtual processors (7 23) >>> x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) >>> Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz >>> >>> ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version [SafePoint >>> Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: >>> 0xfffffd7fff1d0000] Logical CPUs per core: 2 >>> UseSSE=4 UseAVX=1 UseAES=1 >>> Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 >>> bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes 576 >>> PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 cores >>> per cpu, 2 threads per core) family 6 model 45 stepping 6, cmov, cx8, >>> fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, >>> ht, tsc, tscinvbit, tscinv >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 1/30/13 9:45 AM, Markus Gr?nlund wrote: >>>> Hi Mikael, >>>> >>>> I wonder if you are looking at the right section in the manual (and >>>> which manual?) here? >>>> >>>> I am using information in Intel Application note 485: >>>> >>>> http://www.intel.com/content/www/us/en/processors/processor-identific >>>> a >>>> tion-cpuid-instruction-note.html >>>> >>>> Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together >>>> with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the >>>> different levels in the cpu topology you are interested in. Results >>>> are given in EBX[15:0] [31:16] == reserved. >>>> >>>> >>>> "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. >>>> dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the >>>> difference is? Is that maybe a better candidate for this?" >>>> >>>> CPUID04 EAX[31:26] is giving you the number of cores [per cpu >>>> package] using the legacy "initial APICID (8-bits)" systems. This >>>> combined with CPUID 01[logical threads per cpu package] is the >>>> legacy way of cpu identification. It is cannot give you as much >>>> info as topology however. >>>> >>>> Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) >>>> for identification (SMT, Core, Pkg), and does not use "initial >>>> APICID". >>>> >>>> So: >>>> >>>> EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == >>>> (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) >>>> EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in >>>> _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) >>>> ... >>>> >>>> Hope this clarifies >>>> >>>> Cheers >>>> Markus >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Mikael Vidstedt >>>> Sent: den 30 januari 2013 17:30 >>>> To: Markus Gr?nlund >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>>> wrong for cpuid 0xb topology case >>>> >>>> >>>> Looking at the Intel manual for CPUID 0Bh it basically says that >>>> one should not use the value in EBX[15:0] for anything other than >>>> "...display/diagnostic purposes". There's also a cores_per_cpu in >>>> CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do >>>> you happen to know what the difference is? Is that maybe a better >>>> candidate for this? >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >>>>> Hi again, >>>>> >>>>> Apologies for posting the wrong webrev link, this is the one I >>>>> wanted to submit: >>>>> >>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >>>>> >>>>> >>>>> Thanks Mikael for the heads up >>>>> >>>>> Cheers >>>>> Markus >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Mikael Gerdin >>>>> Sent: den 29 januari 2013 10:59 >>>>> To: Markus Gr?nlund >>>>> Cc: hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>>>> wrong for cpuid 0xb topology case >>>>> >>>>> Markus, >>>>> >>>>> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> Kindly asking for review for the following very simple change in >>>>>> the logic for number of cores for CPUID 0xb topology. >>>>>> >>>>>> >>>>>> >>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>>>> >>>>>> Webrev: >>>>>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webrev0 >>>>>> 1 >>>>>> / >>>>> This URL is not available from outside Oracle. >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> >>>>>> Also need someone to sponsor this putback. >>>>>> >>>>>> >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> Markus >>>>>> >>>> From markus.gronlund at oracle.com Wed Jan 30 13:24:01 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 13:24:01 -0800 (PST) Subject: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case In-Reply-To: <510988E7.1070304@oracle.com> References: <51079D51.4070504@oracle.com> <51094A7E.5050909@oracle.com> <51096775.7080902@oracle.com> <51096D33.7090309@oracle.com> <7b2b95e6-facb-4abb-958c-3a98911dd796@default> <510973E5.5020706@oracle.com> <510988E7.1070304@oracle.com> Message-ID: <9d401436-7676-489b-8be1-5c3270b8c16c@default> Thanks a lot for pointing me to this Micke! That is a very interesting ** indeed, "must not use EBX[15:0] to enumerate processor topology of the system" I guess what is referred to here is exactly what that Vladimir just showed, that the value in EBX[15:0] is not an accurate number of cores on a CPU package. Instead EAX[4:0] should be used to find the level shifts for creating the mask widths for proper sub id extraction (SMT, Core, Pkg) from the 2xAPICIDs when doing topology enumeration. Thanks again Mikael /Markus -----Original Message----- From: Mikael Vidstedt Sent: den 30 januari 2013 21:56 To: Vladimir Kozlov Cc: Markus Gr?nlund; hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is wrong for cpuid 0xb topology case For completeness, I was looking at the instruction set reference (from January 2013), page 3-152 and 3-153, and specifically the double star ("**") note for the EBX value. http://download.intel.com/products/processor/manual/253666.pdf Cheers, Mikael On 2013-01-30 11:26, Vladimir Kozlov wrote: > You are welcome. > > Yes, you have to read "small print" not only on financial documents > but also in hw architecture manuals :( > > Regards, > Vladimir > > On 1/30/13 11:09 AM, Markus Gr?nlund wrote: >> Vladimir, >> >> many thanks giving me a good example, I have only had >> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1, so far. >> >> You are right, thank you for showing me this, I did not read the >> details on the Note2 on Core level well enough: >> >> "2. The number of factory-configured logical processors at this level >> is equal to the number of factory-configured cores * the number of >> factory-configured logical processors per core." >> >> It was my (mis)understanding that Core level did not multiply up to >> the SMT level(but id does as the note gives as well as your example >> explains). >> >> Many thanks Vladimir >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: den 30 januari 2013 19:58 >> To: Markus Gr?nlund >> Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >> wrong for cpuid 0xb topology case >> >> No, the example I showed has HT and VM gives correct results: >> >> tpl_cpuidB0_ebx.bits.logical_cpus = 2 >> tpl_cpuidB1_ebx.bits.logical_cpus = 16 >> >> (8 cores per cpu, 2 threads per core) >> >> Vladimir >> >> On 1/30/13 10:47 AM, Markus Gr?nlund wrote: >>> Hi Vladimir, >>> >>> Yes I have noticed that it will give ok results (so far). For >>> example, on my Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, >>> (Sandybridge-EP). >>> >>> I have 8 hw threads (from os::processor_count()) >>> >>> Also, it's using CPUID 0xb (supports topology, 2xAPICID) >>> >>> My values are: >>> >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 <<-- threads per >>> core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores >>> per cpu package >>> >>> Current (wrong) logic does: >>> >>> No of cores per cpu: >>> >>> Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 1 == no of cores == >>> 8 (correct). >>> >>> However, >>> >>> This does not account for CPUs that have HT enabled, i.e if HT is >>> enabled, you will get this: >>> >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 <<-- threads per >>> core _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 <<-- cores >>> per cpu package >>> >>> >>> Returns : _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus = 8 / >>> _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus = 2 == no of cores is >>> now 4, but the real number of cores is 8. >>> >>> So, avoid doing the unnecessary divide operation >>> (no_of_cores_per_pkg) / (no_of_threads_per_core). The correct info >>> is already there. Just return it. >>> >>> Return: _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus // 8 correct >>> >>> >>> Cheers >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: den 30 januari 2013 19:33 >>> To: Markus Gr?nlund >>> Cc: Mikael Vidstedt; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>> wrong for cpuid 0xb topology case >>> >>> Markus, >>> >>> Current code is correct. In what case it is not correct? >>> >>> bash-4.1$ psrinfo -pv >>> The physical processor has 8 cores and 16 virtual processors (0-7 >>> 16-23) >>> The core has 2 virtual processors (0 16) >>> The core has 2 virtual processors (1 17) >>> The core has 2 virtual processors (2 18) >>> The core has 2 virtual processors (3 19) >>> The core has 2 virtual processors (4 20) >>> The core has 2 virtual processors (5 21) >>> The core has 2 virtual processors (6 22) >>> The core has 2 virtual processors (7 23) >>> x86 (GenuineIntel 206D6 family 6 model 45 step 6 clock 2693 MHz) >>> Intel(r) Xeon(r) CPU E5-2680 0 @ 2.70GHz >>> >>> ash-4.1$ java -XX:+PrintMiscellaneous -XX:+Verbose -version >>> [SafePoint Polling address: 0xfffffd7fff1e0000] [Memory Serialize Page address: >>> 0xfffffd7fff1d0000] Logical CPUs per core: 2 >>> UseSSE=4 UseAVX=1 UseAES=1 >>> Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 >>> bytes PrefetchCopyIntervalInBytes 576 PrefetchScanIntervalInBytes >>> 576 PrefetchFieldsAhead 1 ContendedPaddingWidth 128 CPU:total 32 (8 >>> cores per cpu, 2 threads per core) family 6 model 45 stepping 6, >>> cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, >>> popcnt, avx, aes, ht, tsc, tscinvbit, tscinv >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 1/30/13 9:45 AM, Markus Gr?nlund wrote: >>>> Hi Mikael, >>>> >>>> I wonder if you are looking at the right section in the manual (and >>>> which manual?) here? >>>> >>>> I am using information in Intel Application note 485: >>>> >>>> http://www.intel.com/content/www/us/en/processors/processor-identif >>>> ic >>>> a >>>> tion-cpuid-instruction-note.html >>>> >>>> Section 5.1.12 page 41 describes CPUID 0xb. Essentially, together >>>> with EAX=0xb, you pass in subleafs (0, 1, 2...) in ECX for the >>>> different levels in the cpu topology you are interested in. Results >>>> are given in EBX[15:0] [31:16] == reserved. >>>> >>>> >>>> "There's also a cores_per_cpu in CPUID 04h EAX[31:26] (aka. >>>> dcp_cpuid4_eax.bits.cores_per_cpu), do you happen to know what the >>>> difference is? Is that maybe a better candidate for this?" >>>> >>>> CPUID04 EAX[31:26] is giving you the number of cores [per cpu >>>> package] using the legacy "initial APICID (8-bits)" systems. This >>>> combined with CPUID 01[logical threads per cpu package] is the >>>> legacy way of cpu identification. It is cannot give you as much >>>> info as topology however. >>>> >>>> Processors supporting CPUID 0xb is using 3-level 2xAPICID (32-bit) >>>> for identification (SMT, Core, Pkg), and does not use "initial >>>> APICID". >>>> >>>> So: >>>> >>>> EAX=0xb, ECX=0 == EBX[15:0] == no_of_logical_threads_per_core == >>>> (stored in _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus) >>>> EAX=0xb, ECX=1 == EBX[15:0] == no_of_cores_per_pkg == (stored in >>>> _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus) >>>> ... >>>> >>>> Hope this clarifies >>>> >>>> Cheers >>>> Markus >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Mikael Vidstedt >>>> Sent: den 30 januari 2013 17:30 >>>> To: Markus Gr?nlund >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>>> wrong for cpuid 0xb topology case >>>> >>>> >>>> Looking at the Intel manual for CPUID 0Bh it basically says that >>>> one should not use the value in EBX[15:0] for anything other than >>>> "...display/diagnostic purposes". There's also a cores_per_cpu in >>>> CPUID 04h EAX[31:26] (aka. dcp_cpuid4_eax.bits.cores_per_cpu), do >>>> you happen to know what the difference is? Is that maybe a better >>>> candidate for this? >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 1/29/2013 2:10 AM, Markus Gr?nlund wrote: >>>>> Hi again, >>>>> >>>>> Apologies for posting the wrong webrev link, this is the one I >>>>> wanted to submit: >>>>> >>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007069/webrev01/ >>>>> >>>>> >>>>> Thanks Mikael for the heads up >>>>> >>>>> Cheers >>>>> Markus >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Mikael Gerdin >>>>> Sent: den 29 januari 2013 10:59 >>>>> To: Markus Gr?nlund >>>>> Cc: hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR(XXS): JDK-8007069 VM_Version_x86 cores per cpu is >>>>> wrong for cpuid 0xb topology case >>>>> >>>>> Markus, >>>>> >>>>> On 2013-01-29 10:54, Markus Gr?nlund wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> Kindly asking for review for the following very simple change in >>>>>> the logic for number of cores for CPUID 0xb topology. >>>>>> >>>>>> >>>>>> >>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007069 >>>>>> >>>>>> Webrev: >>>>>> http://wikifiles.se.oracle.com/dev/mgronlun/webrevs/8007069/webre >>>>>> v0 >>>>>> 1 >>>>>> / >>>>> This URL is not available from outside Oracle. >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> >>>>>> Also need someone to sponsor this putback. >>>>>> >>>>>> >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> Markus >>>>>> >>>> From coleen.phillimore at oracle.com Wed Jan 30 14:53:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Jan 2013 17:53:34 -0500 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <5109A46E.6060500@oracle.com> Vote: yes On 1/25/2013 11:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He > is a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes > for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From coleen.phillimore at oracle.com Wed Jan 30 15:04:43 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Jan 2013 18:04:43 -0500 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <51075003.9000307@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> <5106F91B.4040900@oracle.com> <51075003.9000307@oracle.com> Message-ID: <5109A70B.2060109@oracle.com> This looks really good! Thanks for doing the refactoring! Coleen On 1/28/2013 11:28 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > This is a version with a refactoring you requested: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.3/ > > > Now, the NameAndType, FieldRef, InterfaceMethodRef and MethodRef use > the find_or_append_indirect_entry(). > > > Thanks, > Serguei > > > On 1/28/13 2:18 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> >> This is a new webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ >> >> >> As you pointed out, the InvokeDynamic entry support should also do >> cross-checks with >> the bootstrap method operands (arguments) and recursive extra appends >> if necessary. >> >> I've filed a separate bug to track this issue: >> https://jbs.oracle.com/bugs/browse/JDK-8007037 >> >> I want to separate this issue to be able to integrate what I have now >> and concentrate on the rest later. >> The VM SQE team developed new INDY tests that cover the >> RedefineClasses issues. >> I hope to adopt and use new tests soon to make sure most of the >> issues are actually resolved. >> >> >> Thanks, >> Serguei >> >> >> On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> >>> Thank you a lot for the review! >>> >>> On 1/24/13 3:55 PM, Coleen Phillimore wrote: >>>> >>>> Hi Serguei, >>>> >>>> Putting functions in alphabetical order seems silly, it's better to >>>> have utility functions directly above (or below) the function that >>>> calls them. I'd take out the comment. >>>> >>>> I have started looking at this code a bit. This function >>>> find_or_append_indirect_entry() should be used for the other >>>> indirect entries also, shouldn't it? The code looks familiar to >>>> the inside of the case statement to FieldRef, InterfaceRef and >>>> MethodRef. >>> >>> You've got it right. >>> Yes, I noticed it but did not want to mess with it until it is >>> proven to work well. >>> My plan was to fix it for the FieldRef, InterfaceRef and MethodRef >>> in a next round of fixes. >>> >>>> >>>> Also is boot_spec an indirect index too that has to be appended? >>>> >>>> 564 int boot_spec = >>>> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); >>> >>> This is a nice catch, will fix it. >>> I thought, it is an index into the operands array, but it refers to >>> a CONSTANT_MethodHandle element. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>>>> Christian, >>>>> >>>>> >>>>> Thank you a lot for the review! >>>>> >>>>> Nice catch with the ordering. >>>>> In fact, I tried to follow the order but missed that the >>>>> find_new_index should go first. :) >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>>> Please, review the fix for: >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>>>> >>>>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>>>> >>>>>> + // Support for constant pool merging (these routines are in >>>>>> alpha order): >>>>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, >>>>>> TRAPS); >>>>>> + int find_or_append_indirect_entry(constantPoolHandle >>>>>> scratch_cp, int scratch_i, >>>>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>>>> int find_new_index(int old_index); >>>>>> >>>>>> Not really alpha order ;-) >>>>>> >>>>>> Otherwise this looks good (as far as I can tell). >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> Summary: >>>>>>> Need a support for invokedynamic entry kinds when new and old >>>>>>> constant pools are merged. >>>>>>> >>>>>>> Testing: >>>>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>>>> Asked the VM SQE team to develop new INDY tests for better >>>>>>> coverage. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Jan 30 15:15:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2013 15:15:57 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5109A70B.2060109@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> <5106F91B.4040900@oracle.com> <51075003.9000307@oracle.com> <5109A70B.2060109@oracle.com> Message-ID: <5109A9AD.2080203@oracle.com> Thanks, Coleen! Serguei On 1/30/13 3:04 PM, Coleen Phillimore wrote: > > This looks really good! Thanks for doing the refactoring! > Coleen > > On 1/28/2013 11:28 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> This is a version with a refactoring you requested: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.3/ >> >> >> Now, the NameAndType, FieldRef, InterfaceMethodRef and MethodRef use >> the find_or_append_indirect_entry(). >> >> >> Thanks, >> Serguei >> >> >> On 1/28/13 2:18 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> >>> This is a new webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ >>> >>> >>> As you pointed out, the InvokeDynamic entry support should also do >>> cross-checks with >>> the bootstrap method operands (arguments) and recursive extra >>> appends if necessary. >>> >>> I've filed a separate bug to track this issue: >>> https://jbs.oracle.com/bugs/browse/JDK-8007037 >>> >>> I want to separate this issue to be able to integrate what I have >>> now and concentrate on the rest later. >>> The VM SQE team developed new INDY tests that cover the >>> RedefineClasses issues. >>> I hope to adopt and use new tests soon to make sure most of the >>> issues are actually resolved. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> >>>> Thank you a lot for the review! >>>> >>>> On 1/24/13 3:55 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Putting functions in alphabetical order seems silly, it's better >>>>> to have utility functions directly above (or below) the function >>>>> that calls them. I'd take out the comment. >>>>> >>>>> I have started looking at this code a bit. This function >>>>> find_or_append_indirect_entry() should be used for the other >>>>> indirect entries also, shouldn't it? The code looks familiar to >>>>> the inside of the case statement to FieldRef, InterfaceRef and >>>>> MethodRef. >>>> >>>> You've got it right. >>>> Yes, I noticed it but did not want to mess with it until it is >>>> proven to work well. >>>> My plan was to fix it for the FieldRef, InterfaceRef and MethodRef >>>> in a next round of fixes. >>>> >>>>> >>>>> Also is boot_spec an indirect index too that has to be appended? >>>>> >>>>> 564 int boot_spec = >>>>> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); >>>> >>>> This is a nice catch, will fix it. >>>> I thought, it is an index into the operands array, but it refers to >>>> a CONSTANT_MethodHandle element. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Christian, >>>>>> >>>>>> >>>>>> Thank you a lot for the review! >>>>>> >>>>>> Nice catch with the ordering. >>>>>> In fact, I tried to follow the order but missed that the >>>>>> find_new_index should go first. :) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>>>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>>> Please, review the fix for: >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>>>>> >>>>>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>>>>> >>>>>>> + // Support for constant pool merging (these routines are in >>>>>>> alpha order): >>>>>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>>>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, >>>>>>> TRAPS); >>>>>>> + int find_or_append_indirect_entry(constantPoolHandle >>>>>>> scratch_cp, int scratch_i, >>>>>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, >>>>>>> TRAPS); >>>>>>> int find_new_index(int old_index); >>>>>>> >>>>>>> Not really alpha order ;-) >>>>>>> >>>>>>> Otherwise this looks good (as far as I can tell). >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> Summary: >>>>>>>> Need a support for invokedynamic entry kinds when new and old >>>>>>>> constant pools are merged. >>>>>>>> >>>>>>>> Testing: >>>>>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>>>>> Asked the VM SQE team to develop new INDY tests for better >>>>>>>> coverage. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From jon.masamitsu at oracle.com Wed Jan 30 18:02:46 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 30 Jan 2013 18:02:46 -0800 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <5109D0C6.8050306@oracle.com> Vote: yes On 1/25/2013 8:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He > is a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes > for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From stefan.karlsson at oracle.com Wed Jan 30 23:27:26 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 31 Jan 2013 08:27:26 +0100 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <510A1CDE.3020608@oracle.com> vote: yes StefanK On 2013-01-25 17:02, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He is > a key contributor to the Hotspot Runtime group. He has implemented > Native Memory Tracking, an important new feature, the hs_err log > decoding from within the VM, as well as various other runtime fixes > for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two > weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on > thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From david.holmes at oracle.com Thu Jan 31 00:25:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2013 18:25:57 +1000 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <5102B299.5020605@oracle.com> References: <5102B299.5020605@oracle.com> Message-ID: <510A2A95.5030209@oracle.com> Joe, On 26/01/2013 2:28 AM, Joe Provino wrote: > 2 ffiles changed. > > Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 This seems to mix fixes for two different issues. The removal of the INCLUDE_ALL_GC guard would seem to indicate there is a problem if not building all GCs ie with the minimal VM - is that the case? David > joe From stefan.karlsson at oracle.com Thu Jan 31 00:40:01 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 31 Jan 2013 09:40:01 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> <51094787.8020904@oracle.com> Message-ID: <510A2DE1.90403@oracle.com> On 2013-01-30 17:22, Stefan Karlsson wrote: > On 30 jan 2013, at 17:17, Jon Masamitsu wrote: > >> Comment below. >> >> On 1/29/2013 2:01 PM, Stefan Karlsson wrote: >>> On 29 jan 2013, at 22:53, Jon Masamitsu wrote: >>> >>>> Stefan, >>>> >>>> Changes look correct. >>> Thanks. >>> >>>> Did you consider calculating the value for endReserve() all >>>> in the VM (similar to the way ReserveForAllocationPrefetch >>>> is calculated during initialization) and passing the value >>>> to the SA the way ReserveForAllocationPrefetch is passed? >>>> If ReserveForAllocationPrefetch is not used anywhere else, >>>> you could substitute it (TLabEndReserve as a possible name) >>>> for ReserveForAllocationPrefetch. >>> No i didn't think about that. I just tried to mimic the VM code in the SA code. Would you prefer if I changed it to use your alternative solution? >> Scrap the alternate fix suggestion but I'd suggest changing the name >> >> intArrayHeaderSize >> >> to >> >> minFillerArraySize >> >> What caught my eye about this change is that it was hard >> to understand the use of intArrayHeaderSize unless you knew >> that tlab's had filler arrays inserted in them to make them >> parsable and hotspot saved room at the end of each tlab so >> that a filler object could always be inserted. If you >> make the name change that give the reader a clue to that. > Sure, I'll update the name. Thanks again for the review. Updated version: http://cr.openjdk.java.net/~stefank/8004710/webrev.01/ I need a second review. thanks, StefanK > > StefanK > >> Ship it. >> >> Jon >> >> >>> thanks, >>> StefanK >>> >>> >>>> Jon >>>> >>>> On 01/29/13 02:58, Stefan Karlsson wrote: >>>>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>>>> >>>>> This bug is in the GC specific code in the SA agent. >>>>> >>>>> From the bug report: >>>>> There's a bug in ObjectHeap.collectLiveRegions(), which tries to collect the regions of the heap that contain live objects. It removes the [top, end) regions of a TLAB, since we don't have live objects in those regions. Unfortunately, this doesn't consider the small alignment_reserve() part at the end of the TLAB, and we try to decode an object in that unused memory region. >>>>> >>>>> It's not related to the PermGen removal, but the failure mode was probably changed. >>>>> >>>>> thanks, >>>>> StefanK >>>>> From bengt.rutisson at oracle.com Thu Jan 31 01:09:30 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 31 Jan 2013 10:09:30 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <510A2DE1.90403@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> <51094787.8020904@oracle.com> <510A2DE1.90403@oracle.com> Message-ID: <510A34CA.1010000@oracle.com> Stefan, On 1/31/13 9:40 AM, Stefan Karlsson wrote: > On 2013-01-30 17:22, Stefan Karlsson wrote: >> On 30 jan 2013, at 17:17, Jon Masamitsu >> wrote: >> >>> Comment below. >>> >>> On 1/29/2013 2:01 PM, Stefan Karlsson wrote: >>>> On 29 jan 2013, at 22:53, Jon Masamitsu >>>> wrote: >>>> >>>>> Stefan, >>>>> >>>>> Changes look correct. >>>> Thanks. >>>> >>>>> Did you consider calculating the value for endReserve() all >>>>> in the VM (similar to the way ReserveForAllocationPrefetch >>>>> is calculated during initialization) and passing the value >>>>> to the SA the way ReserveForAllocationPrefetch is passed? >>>>> If ReserveForAllocationPrefetch is not used anywhere else, >>>>> you could substitute it (TLabEndReserve as a possible name) >>>>> for ReserveForAllocationPrefetch. >>>> No i didn't think about that. I just tried to mimic the VM code in >>>> the SA code. Would you prefer if I changed it to use your >>>> alternative solution? >>> Scrap the alternate fix suggestion but I'd suggest changing the name >>> >>> intArrayHeaderSize >>> >>> to >>> >>> minFillerArraySize >>> >>> What caught my eye about this change is that it was hard >>> to understand the use of intArrayHeaderSize unless you knew >>> that tlab's had filler arrays inserted in them to make them >>> parsable and hotspot saved room at the end of each tlab so >>> that a filler object could always be inserted. If you >>> make the name change that give the reader a clue to that. >> Sure, I'll update the name. Thanks again for the review. > Updated version: > http://cr.openjdk.java.net/~stefank/8004710/webrev.01/ > > I need a second review. Looks good to me. One minor thing: ThreadLocalAllocBuffer:: endReserve(). Was it intended to leave the variable intArrayHeaderSize in there? Looks like it was just left from the renaming. Bengt > > thanks, > StefanK >> >> StefanK >> >>> Ship it. >>> >>> Jon >>> >>> >>>> thanks, >>>> StefanK >>>> >>>> >>>>> Jon >>>>> >>>>> On 01/29/13 02:58, Stefan Karlsson wrote: >>>>>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>>>>> >>>>>> This bug is in the GC specific code in the SA agent. >>>>>> >>>>>> From the bug report: >>>>>> There's a bug in ObjectHeap.collectLiveRegions(), which tries to >>>>>> collect the regions of the heap that contain live objects. It >>>>>> removes the [top, end) regions of a TLAB, since we don't have >>>>>> live objects in those regions. Unfortunately, this doesn't >>>>>> consider the small alignment_reserve() part at the end of the >>>>>> TLAB, and we try to decode an object in that unused memory region. >>>>>> >>>>>> It's not related to the PermGen removal, but the failure mode was >>>>>> probably changed. >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>>> > From stefan.karlsson at oracle.com Thu Jan 31 01:37:27 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 31 Jan 2013 10:37:27 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <510A34CA.1010000@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> <51094787.8020904@oracle.com> <510A2DE1.90403@oracle.com> <510A34CA.1010000@oracle.com> Message-ID: <510A3B57.2090809@oracle.com> On 2013-01-31 10:09, Bengt Rutisson wrote: > > Stefan, > > On 1/31/13 9:40 AM, Stefan Karlsson wrote: >> On 2013-01-30 17:22, Stefan Karlsson wrote: >>> On 30 jan 2013, at 17:17, Jon Masamitsu >>> wrote: >>> >>>> Comment below. >>>> >>>> On 1/29/2013 2:01 PM, Stefan Karlsson wrote: >>>>> On 29 jan 2013, at 22:53, Jon Masamitsu >>>>> wrote: >>>>> >>>>>> Stefan, >>>>>> >>>>>> Changes look correct. >>>>> Thanks. >>>>> >>>>>> Did you consider calculating the value for endReserve() all >>>>>> in the VM (similar to the way ReserveForAllocationPrefetch >>>>>> is calculated during initialization) and passing the value >>>>>> to the SA the way ReserveForAllocationPrefetch is passed? >>>>>> If ReserveForAllocationPrefetch is not used anywhere else, >>>>>> you could substitute it (TLabEndReserve as a possible name) >>>>>> for ReserveForAllocationPrefetch. >>>>> No i didn't think about that. I just tried to mimic the VM code in >>>>> the SA code. Would you prefer if I changed it to use your >>>>> alternative solution? >>>> Scrap the alternate fix suggestion but I'd suggest changing the name >>>> >>>> intArrayHeaderSize >>>> >>>> to >>>> >>>> minFillerArraySize >>>> >>>> What caught my eye about this change is that it was hard >>>> to understand the use of intArrayHeaderSize unless you knew >>>> that tlab's had filler arrays inserted in them to make them >>>> parsable and hotspot saved room at the end of each tlab so >>>> that a filler object could always be inserted. If you >>>> make the name change that give the reader a clue to that. >>> Sure, I'll update the name. Thanks again for the review. >> Updated version: >> http://cr.openjdk.java.net/~stefank/8004710/webrev.01/ >> >> I need a second review. > > Looks good to me. > > One minor thing: > > ThreadLocalAllocBuffer:: endReserve(). Was it intended to leave the > variable intArrayHeaderSize in there? Looks like it was just left from > the renaming. I left it there on purpose. The SA code hides the Array.headerSizeInBytes() function, so I figured I could use the public Array.baseOffsetInBytes(BasicType.T_INT) instead. But since it's actually the header size I'm after (See: ThreadLocalAllocBuffer::end_reserve()), I put the result in a variable with a name that hinted about that. For reference: In src/share/vm/memory/threadLocalAllocBuffer.hpp // Reserve space at the end of TLAB static size_t end_reserve() { int reserve_size = typeArrayOopDesc::header_size(T_INT); return MAX2(reserve_size, VM_Version::reserve_for_allocation_prefetch()); } Do you want me to remove the intArrayHeaderSize variable? StefanK > > Bengt > >> >> thanks, >> StefanK >>> >>> StefanK >>> >>>> Ship it. >>>> >>>> Jon >>>> >>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>> >>>>>> Jon >>>>>> >>>>>> On 01/29/13 02:58, Stefan Karlsson wrote: >>>>>>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>>>>>> >>>>>>> This bug is in the GC specific code in the SA agent. >>>>>>> >>>>>>> From the bug report: >>>>>>> There's a bug in ObjectHeap.collectLiveRegions(), which tries to >>>>>>> collect the regions of the heap that contain live objects. It >>>>>>> removes the [top, end) regions of a TLAB, since we don't have >>>>>>> live objects in those regions. Unfortunately, this doesn't >>>>>>> consider the small alignment_reserve() part at the end of the >>>>>>> TLAB, and we try to decode an object in that unused memory region. >>>>>>> >>>>>>> It's not related to the PermGen removal, but the failure mode >>>>>>> was probably changed. >>>>>>> >>>>>>> thanks, >>>>>>> StefanK >>>>>>> >> > From bengt.rutisson at oracle.com Thu Jan 31 01:47:01 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 31 Jan 2013 10:47:01 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <510A3B57.2090809@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> <51094787.8020904@oracle.com> <510A2DE1.90403@oracle.com> <510A34CA.1010000@oracle.com> <510A3B57.2090809@oracle.com> Message-ID: <510A3D95.4020803@oracle.com> On 1/31/13 10:37 AM, Stefan Karlsson wrote: > On 2013-01-31 10:09, Bengt Rutisson wrote: >> >> Stefan, >> >> On 1/31/13 9:40 AM, Stefan Karlsson wrote: >>> On 2013-01-30 17:22, Stefan Karlsson wrote: >>>> On 30 jan 2013, at 17:17, Jon Masamitsu >>>> wrote: >>>> >>>>> Comment below. >>>>> >>>>> On 1/29/2013 2:01 PM, Stefan Karlsson wrote: >>>>>> On 29 jan 2013, at 22:53, Jon >>>>>> Masamitsu wrote: >>>>>> >>>>>>> Stefan, >>>>>>> >>>>>>> Changes look correct. >>>>>> Thanks. >>>>>> >>>>>>> Did you consider calculating the value for endReserve() all >>>>>>> in the VM (similar to the way ReserveForAllocationPrefetch >>>>>>> is calculated during initialization) and passing the value >>>>>>> to the SA the way ReserveForAllocationPrefetch is passed? >>>>>>> If ReserveForAllocationPrefetch is not used anywhere else, >>>>>>> you could substitute it (TLabEndReserve as a possible name) >>>>>>> for ReserveForAllocationPrefetch. >>>>>> No i didn't think about that. I just tried to mimic the VM code >>>>>> in the SA code. Would you prefer if I changed it to use your >>>>>> alternative solution? >>>>> Scrap the alternate fix suggestion but I'd suggest changing the name >>>>> >>>>> intArrayHeaderSize >>>>> >>>>> to >>>>> >>>>> minFillerArraySize >>>>> >>>>> What caught my eye about this change is that it was hard >>>>> to understand the use of intArrayHeaderSize unless you knew >>>>> that tlab's had filler arrays inserted in them to make them >>>>> parsable and hotspot saved room at the end of each tlab so >>>>> that a filler object could always be inserted. If you >>>>> make the name change that give the reader a clue to that. >>>> Sure, I'll update the name. Thanks again for the review. >>> Updated version: >>> http://cr.openjdk.java.net/~stefank/8004710/webrev.01/ >>> >>> I need a second review. >> >> Looks good to me. >> >> One minor thing: >> >> ThreadLocalAllocBuffer:: endReserve(). Was it intended to leave the >> variable intArrayHeaderSize in there? Looks like it was just left >> from the renaming. > > I left it there on purpose. The SA code hides the > Array.headerSizeInBytes() function, so I figured I could use the > public Array.baseOffsetInBytes(BasicType.T_INT) instead. But since > it's actually the header size I'm after (See: > ThreadLocalAllocBuffer::end_reserve()), I put the result in a variable > with a name that hinted about that. > > For reference: In src/share/vm/memory/threadLocalAllocBuffer.hpp > // Reserve space at the end of TLAB > static size_t end_reserve() { > int reserve_size = typeArrayOopDesc::header_size(T_INT); > return MAX2(reserve_size, > VM_Version::reserve_for_allocation_prefetch()); > } > > Do you want me to remove the intArrayHeaderSize variable? Thanks for the explanation. I'm fine with leaving it in. But since I didn't get it from just reading the code, maybe this is a case where it is better to add a comment than using a variable name? Normally I would argue the other way around... :) Bengt > > StefanK > >> >> Bengt >> >>> >>> thanks, >>> StefanK >>>> >>>> StefanK >>>> >>>>> Ship it. >>>>> >>>>> Jon >>>>> >>>>> >>>>>> thanks, >>>>>> StefanK >>>>>> >>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 01/29/13 02:58, Stefan Karlsson wrote: >>>>>>>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>>>>>>> >>>>>>>> This bug is in the GC specific code in the SA agent. >>>>>>>> >>>>>>>> From the bug report: >>>>>>>> There's a bug in ObjectHeap.collectLiveRegions(), which tries >>>>>>>> to collect the regions of the heap that contain live objects. >>>>>>>> It removes the [top, end) regions of a TLAB, since we don't >>>>>>>> have live objects in those regions. Unfortunately, this doesn't >>>>>>>> consider the small alignment_reserve() part at the end of the >>>>>>>> TLAB, and we try to decode an object in that unused memory region. >>>>>>>> >>>>>>>> It's not related to the PermGen removal, but the failure mode >>>>>>>> was probably changed. >>>>>>>> >>>>>>>> thanks, >>>>>>>> StefanK >>>>>>>> >>> >> > From stefan.karlsson at oracle.com Thu Jan 31 01:59:44 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 31 Jan 2013 10:59:44 +0100 Subject: Review request: 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal In-Reply-To: <510A3D95.4020803@oracle.com> References: <5107AB38.4080107@oracle.com> <510844CD.7050907@oracle.com> <0F27E02C-D9F7-400D-BF00-03FE2FD21ACA@oracle.com> <51094787.8020904@oracle.com> <510A2DE1.90403@oracle.com> <510A34CA.1010000@oracle.com> <510A3B57.2090809@oracle.com> <510A3D95.4020803@oracle.com> Message-ID: <510A4090.2000301@oracle.com> On 2013-01-31 10:47, Bengt Rutisson wrote: > On 1/31/13 10:37 AM, Stefan Karlsson wrote: >> On 2013-01-31 10:09, Bengt Rutisson wrote: >>> >>> Stefan, >>> >>> On 1/31/13 9:40 AM, Stefan Karlsson wrote: >>>> On 2013-01-30 17:22, Stefan Karlsson wrote: >>>>> On 30 jan 2013, at 17:17, Jon Masamitsu >>>>> wrote: >>>>> >>>>>> Comment below. >>>>>> >>>>>> On 1/29/2013 2:01 PM, Stefan Karlsson wrote: >>>>>>> On 29 jan 2013, at 22:53, Jon >>>>>>> Masamitsu wrote: >>>>>>> >>>>>>>> Stefan, >>>>>>>> >>>>>>>> Changes look correct. >>>>>>> Thanks. >>>>>>> >>>>>>>> Did you consider calculating the value for endReserve() all >>>>>>>> in the VM (similar to the way ReserveForAllocationPrefetch >>>>>>>> is calculated during initialization) and passing the value >>>>>>>> to the SA the way ReserveForAllocationPrefetch is passed? >>>>>>>> If ReserveForAllocationPrefetch is not used anywhere else, >>>>>>>> you could substitute it (TLabEndReserve as a possible name) >>>>>>>> for ReserveForAllocationPrefetch. >>>>>>> No i didn't think about that. I just tried to mimic the VM code >>>>>>> in the SA code. Would you prefer if I changed it to use your >>>>>>> alternative solution? >>>>>> Scrap the alternate fix suggestion but I'd suggest changing the name >>>>>> >>>>>> intArrayHeaderSize >>>>>> >>>>>> to >>>>>> >>>>>> minFillerArraySize >>>>>> >>>>>> What caught my eye about this change is that it was hard >>>>>> to understand the use of intArrayHeaderSize unless you knew >>>>>> that tlab's had filler arrays inserted in them to make them >>>>>> parsable and hotspot saved room at the end of each tlab so >>>>>> that a filler object could always be inserted. If you >>>>>> make the name change that give the reader a clue to that. >>>>> Sure, I'll update the name. Thanks again for the review. >>>> Updated version: >>>> http://cr.openjdk.java.net/~stefank/8004710/webrev.01/ >>>> >>>> I need a second review. >>> >>> Looks good to me. >>> >>> One minor thing: >>> >>> ThreadLocalAllocBuffer:: endReserve(). Was it intended to leave the >>> variable intArrayHeaderSize in there? Looks like it was just left >>> from the renaming. >> >> I left it there on purpose. The SA code hides the >> Array.headerSizeInBytes() function, so I figured I could use the >> public Array.baseOffsetInBytes(BasicType.T_INT) instead. But since >> it's actually the header size I'm after (See: >> ThreadLocalAllocBuffer::end_reserve()), I put the result in a >> variable with a name that hinted about that. >> >> For reference: In src/share/vm/memory/threadLocalAllocBuffer.hpp >> // Reserve space at the end of TLAB >> static size_t end_reserve() { >> int reserve_size = typeArrayOopDesc::header_size(T_INT); >> return MAX2(reserve_size, >> VM_Version::reserve_for_allocation_prefetch()); >> } >> >> Do you want me to remove the intArrayHeaderSize variable? > > Thanks for the explanation. I'm fine with leaving it in. But since I > didn't get it from just reading the code, maybe this is a case where > it is better to add a comment than using a variable name? Normally I > would argue the other way around... :) http://cr.openjdk.java.net/~stefank/8004710/webrev.02/ I just removed the variable. Now endReserve() looks like this: private long endReserve() { long minFillerArraySize = Array.baseOffsetInBytes(BasicType.T_INT); long reserveForAllocationPrefetch = VM.getVM().getReserveForAllocationPrefetch(); long heapWordSize = VM.getVM().getHeapWordSize(); return Math.max(minFillerArraySize, reserveForAllocationPrefetch * heapWordSize); } I think it's good enough, since it's even more descriptive than the C++ code that it tries to mimic. thanks, StefanK > > Bengt > > >> >> StefanK >> >>> >>> Bengt >>> >>>> >>>> thanks, >>>> StefanK >>>>> >>>>> StefanK >>>>> >>>>>> Ship it. >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> StefanK >>>>>>> >>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On 01/29/13 02:58, Stefan Karlsson wrote: >>>>>>>>> http://cr.openjdk.java.net/~stefank/8004710/webrev/ >>>>>>>>> >>>>>>>>> This bug is in the GC specific code in the SA agent. >>>>>>>>> >>>>>>>>> From the bug report: >>>>>>>>> There's a bug in ObjectHeap.collectLiveRegions(), which tries >>>>>>>>> to collect the regions of the heap that contain live objects. >>>>>>>>> It removes the [top, end) regions of a TLAB, since we don't >>>>>>>>> have live objects in those regions. Unfortunately, this >>>>>>>>> doesn't consider the small alignment_reserve() part at the end >>>>>>>>> of the TLAB, and we try to decode an object in that unused >>>>>>>>> memory region. >>>>>>>>> >>>>>>>>> It's not related to the PermGen removal, but the failure mode >>>>>>>>> was probably changed. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> StefanK >>>>>>>>> >>>> >>> >> > From zhengyu.gu at oracle.com Thu Jan 31 09:18:52 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 31 Jan 2013 17:18:52 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130131171900.4420E476EF@hg.openjdk.java.net> Changeset: 21fe158e804b Author: zgu Date: 2013-01-31 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/21fe158e804b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: daa66f8e3d8c Author: zgu Date: 2013-01-31 07:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/daa66f8e3d8c Merge From karen.kinnear at oracle.com Thu Jan 31 12:01:37 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 31 Jan 2013 15:01:37 -0500 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <32E43C74-2CF1-4646-AD7A-B9AC441CA34E@oracle.com> Vote: yes On Jan 25, 2013, at 11:02 AM, Coleen Phillimore wrote: > > I hereby nominate Zhengyu Gu to be an OpenJDK HSX [0] Reviewer [1]. > > Zhengyu is on his third year as a Committer on the HSX project. He is a key contributor to the Hotspot Runtime group. He has implemented Native Memory Tracking, an important new feature, the hs_err log decoding from within the VM, as well as various other runtime fixes for Windows. He has 36 commits to the Hotspot code base currently. > > Votes are due by Friday, February 8, 2013 at 16:00:00 UTC (two weekvoting period). > > Only current HSX project Reviewers [2] are eligible to vote on thisnomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > Coleen Phillimore > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#reviewer > [2]http://openjdk.java.net/projects/#reviewer-vote > [3]http://openjdk.java.net/bylaws#three-vote-consensus > From markus.gronlund at oracle.com Thu Jan 31 13:22:58 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 31 Jan 2013 13:22:58 -0800 (PST) Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE Message-ID: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> Greetings, ? Can I kindly ask for a few reviews and a putback sponsorship for the following change: ? Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ Hotspot JPRT builds/tests : completed successfully ? Comment on issue/fix: ? (windows analysis) ? Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. ? Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. ? // on Windows this creates the following issue when closing a NULL handle to a ?semaphore ? void os::signal_notify(int signal_number) { ? BOOL ret; ? ? Atomic::inc(&pending_signals[signal_number]); ??ret = ::ReleaseSemaphore(sig_sem, 1, NULL);?? <<--- call ReleaseSemaphore on global handle sig_sem which has not been setup/created yet == is NULL (is created in os::signal_init_pd()) ? assert(ret != 0, "ReleaseSemaphore() failed"); <<-- assert traps here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) ?? } ? The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. ? Thanks Markus From zhengyu.gu at oracle.com Thu Jan 31 19:04:04 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 01 Feb 2013 03:04:04 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130201030415.1F4EB47726@hg.openjdk.java.net> Changeset: fada199d881a Author: zgu Date: 2013-01-31 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fada199d881a 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: coleenp, ccheung, hseigel ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/macros.hpp Changeset: 7776955a3a41 Author: zgu Date: 2013-01-31 17:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7776955a3a41 Merge From david.holmes at oracle.com Thu Jan 31 20:46:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 14:46:30 +1000 Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> Message-ID: <510B48A6.7060500@oracle.com> Hi Markus, I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. Can you consider moving TRACE_INITIALIZE instead? Thanks, David On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: > Greetings, > > > > Can I kindly ask for a few reviews and a putback sponsorship for the following change: > > > > Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ > > Hotspot JPRT builds/tests : completed successfully > > > > Comment on issue/fix: > > > > (windows analysis) > > > > Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. > > > > Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. > > > > // on Windows this creates the following issue when closing a NULL handle to a semaphore > > > > void os::signal_notify(int signal_number) { > > BOOL ret; > > > > Atomic::inc(&pending_signals[signal_number]); > > ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call ReleaseSemaphore on global handle sig_sem which has not been setup/created yet == is NULL (is created in os::signal_init_pd()) > > assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) > > > > } > > > > The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. > > > > Thanks > > Markus From vladimir.kozlov at oracle.com Thu Jan 31 22:22:46 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 01 Feb 2013 06:22:46 +0000 Subject: hg: hsx/hsx24/hotspot: 5 new changesets Message-ID: <20130201062259.1E09947739@hg.openjdk.java.net> Changeset: 6a55d9e0b5ea Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6a55d9e0b5ea 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: c3a5ef31cb90 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c3a5ef31cb90 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: e34f4fe352e7 Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e34f4fe352e7 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 0a066b1dfe02 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0a066b1dfe02 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: b3686bbdb7d0 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b3686bbdb7d0 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java From david.holmes at oracle.com Thu Jan 31 22:24:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 16:24:38 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <5102B1DC.4050409@oracle.com> References: <51017FBE.1060106@oracle.com> <51021BA4.9000203@oracle.com> <5102B1DC.4050409@oracle.com> Message-ID: <510B5FA6.8030308@oracle.com> Hi Joe, I think you could simplify this further by deleting lines 3168 - 3186 and change force_serial_gc() to do: static void force_serial_gc() { FLAG_SET_DEFAULT(UseSerialGC, true); UNSUPPORTED_GC_OPTION(UseG1GC); UNSUPPORTED_GC_OPTION(UseParallelGC); UNSUPPORTED_GC_OPTION(UseParallelOldGC); UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); UNSUPPORTED_GC_OPTION(UseParNewGC); FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS suboption } and then: 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined ARM) 3222 force_serial_gc(); 3223 #endif Assuming only serialGC is available on embedded or ARM. David ----- On 26/01/2013 2:25 AM, Joe Provino wrote: > With changes from Bob and David, here is a new webrev: > > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 > > joe > > On 1/25/2013 12:44 AM, David Holmes wrote: >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>> You claim to be defaulting to SerialGC but you don't set UseG1GC to >>> false? >> >> The UNSUPPORTED_OPTION macro does that. >> >> But I don't see anything forcing use of serialGC. And >> force_serial_gc() should not be altered. >> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be available >>> and be used. >> >> Only on those platforms that support it. >> >> David >> >>> Bob. >>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>> >>>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>> >>>> It's a change to one file: arguments.cpp. >>>> >>>> thanks. >>>> >>>> joe >>>